Features

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.

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 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.
• Away report — what happened while you were not watching.
• Agent Mode — a separate mode for building and supervising your own scheduled agents, with its own approval queue.
• Sign in with Apple — account creation with an Apple ID.

Beside the delivery pipeline there is a second mode for agents you define yourself: an authoring surface with versioned definitions, a scheduler that is timezone- and DST-correct, and a catalogue of tools you can connect.

The safety model is the same idea as the gates. Each agent is granted an explicit tool scope; anything destructive lands in an approval queue rather than executing; outbound network access is checked against an allowlist; and rate and cost caps are enforced per agent. A connected tool from the catalogue is projected into that same scope model rather than getting a permission system of its own.

Each project runs in its own managed development container, provisioned by CIAN. There is no server for you to supply, harden or patch, and no SSH access to hand over.

A container has no hostname, no DNS record, no public route and no open port. The only way in is CIAN's own control plane, over an internal service binding that does not traverse the public internet — which is why the tunnel, the certificate authority and the device-certificate enrolment that fronted the earlier bring-your-own-server model were retired outright rather than carried forward.

Source code stays in your repositories and issues stay in your tracker. A project's repository is checked out into the container on each start, using a short-lived credential minted per clone rather than a stored key. Session records and transcripts are kept outside the container, so a container stopping does not lose them — though anything uncommitted in its working tree does not survive, which is a real consequence worth knowing rather than discovering.

Concurrency is capped at five live projects at once, and an idle container is stopped rather than left running.