Features

This page describes capabilities, not plans. Anything listed as built is implemented and covered by tests. Anything that is partly built or not started says so, in the same list, in the same words.

Running work through the pipeline

You bring a tracker issue; CIAN takes it through implementation, review, automated testing, a security scan, a QA deployment, human acceptance and documentation. Agents do the work at each phase. The pipeline decides what is allowed to move forward.

• Work comes from your tracker

  Issues are pulled from the tracker you already use, batched by dependency order so that changes which build on each other are not started in parallel and merged into conflict.

• Isolated workspaces per change

  Each piece of work gets its own checkout, so several changes can be in flight against one repository without sharing a working tree.

• Review, testing, security and docs are phases, not afterthoughts

  Code review, automated testing, security scanning, QA deployment and documentation are each a stage the work has to pass through, with a recorded result — not steps an agent may decide to skip.

• Per-project configuration, signed

  A project's settings live in a versioned manifest committed to the repository. It is schema-validated and signed, and it cannot widen or disable either hard gate — the gate rules are checked against the manifest rather than configured by it.

The two gates

These are the reason the rest exists. Both are enforced in the layer that owns pipeline state transitions, so they apply to every path into the protected stage — an agent's request, a direct API call, a replayed webhook, or an edited project manifest.

• Critical/High security findings block

  Nothing enters code review carrying an unresolved Critical or High finding. The gate reads only durable, recorded scan results for the exact revision being moved — a clean result recorded against an earlier revision does not satisfy it, which closes the obvious bypass of scanning clean code and then changing it.

• Human acceptance is mandatory

  Nothing reaches done without a recorded human approval capturing who approved, when, from what attested device, and exactly which revision they reviewed. Approvals are bound to that revision, so an approval of one build does not silently satisfy the next. There is no timeout that auto-approves.

Scope, stated honestly: the security gate enforces that a clean result exists and is current — the scanning itself is done by the security phase that feeds it. The acceptance gate enforces that a complete, current approval record exists; verifying an approver's identity and device attestation is the job of the surface that submits the approval, not the gate.

The iPad control room

The client is built around the moments a human is genuinely required, so that supervising a running pipeline is something you can do in the time you have rather than something that needs a desk.

• Board and feature explorer — what is in flight, at which phase, and what is blocked.
• Sessions — what agents are doing right now, streamed live.
• Acceptance console — review a finished change and approve or reject it. This is the surface that satisfies the human gate.
• Code review — read the diff behind a change before deciding.
• Sign in with Apple — account creation with an Apple ID.

Your machine, your accounts

CIAN does not host your work. You supply a fresh VPS with root access; it is validated for reachability and freshness before anything is installed, then set up over SSH. Connectivity between the control plane and your machine goes over a tunnel with short-lived certificates rather than a permanently open port, and the credentials that provision it are brokered server-side and consumed once rather than handed to the client.

Source code stays in your repositories and issues stay in your tracker. A running installation is capped at five concurrent projects, and idle projects are suspended rather than left burning your VPS.

Status, component by component

The honest version. Built means implemented and tested. In progress means partly built. Not started means exactly that.

• Built Pipeline engine, phase rules, and both hard gates — including adversarial tests for the bypasses each gate is meant to close.
• Built Security scanning, QA deployment, acceptance records, notification fan-out and documentation phases.
• Built Control plane: account and project registry, live session streaming, per-project isolation.
• Built Project manifest: schema, validation, signing, and the invariants that stop it weakening a gate.
• Built VPS validation, brokered provisioning, fleet health checks and idle suspension.
• Built iPad app foundations and the board, sessions, acceptance console and code review surfaces.
• In progress Sign in with Apple — implemented on both client and server and tested, but not yet exercised end to end against Apple's live servers.
• In progress Remaining iPad surfaces: project setup, away report, preview, settings, and in-app editing.
• In progress Running the agent supervisor on a provisioned VPS — the provisioning path installs a placeholder today, not the real supervisor.
• Not started TestFlight and App Store distribution, and sustained real-world use of CIAN to build CIAN.