The client, inside the pipeline
SDLC 2.0 Policy: clients create tasks directly in the pipeline, and low-risk work ships to production without waiting for a human — the human gate isn't removed, it's replaced by two AI gates. Risk stays contained by access boundaries, hard exclusions and auto-rollback.
Baseline standard → Embedded Client
The pipeline is unchanged — seven phases, human accountability. What changed is who files the task and what replaces the human gate on the low-risk track
risk:* label within 15 min; the requester sees it but cannot change itrepo:* labels and blocking relationsFour rules that keep the speed safe
The goal is to make the client a full participant in delivery without handing over control of risk
The client defines WHAT, the pipeline defines HOW
The requester brings the problem and the acceptance criteria. Route, assignee and speed are decided by the system — not negotiated in chat
Automation never changes scope
Automation moves a task inside approved scope and only changes its state. A new requirement is a new task, not an agent quietly widening the current one
Speed replaces the gate — it doesn't skip it
Fast-track drops no checks. It swaps a human gate for an AI gate: code review and QA stay mandatory, they just run in minutes
"Cannot harm production or data"
Client access is bounded by that principle. Anything where a mistake breaks data, contracts or payments stays behind the pipeline
One intake. Three tracks by risk
Every task enters the same way — and splits after the risk label. Click a track to see its rule
Seven phases — pick one
The route is identical for every client and repository. Colour shows who owns the phase; on fast-track, the gates of phases 04 and 06 are executed by AI
Who owns what
Six roles, four of them automated. Humans stay where a decision is needed, not where execution is
| Role | Type | Responsibility |
|---|---|---|
| Client (Requester) | human | Creates the task, provides description, files and context, accepts the result |
| Linear + Loops | AI | Assesses task risk, applies risk:low / medium / high, routes the assignee and the affected repositories |
| Cyrus · AI Engineer | AI | Implements risk:low tasks, opens a PR within a single repository |
| AI Code Review · CodeRabbit | AI gate | Gate one: code quality, security, regressions |
| AI QA | AI gate | Gate two: acceptance criteria verified on staging |
| Delivery Lead / Tech Lead | human | Human gate for risk:medium+, escalations, fast-track incident retros, repo class changes |
Definition of Ready — the entry ticket
A task is valid for the pipeline once all five conditions are met. Try it: toggle the items and watch what happens
How a task earns its route
Loops analyses the description, the attachments and the areas of the codebase involved. Hard exclusions are checked before scoring — and override any verdict the model produces
Try it: which track would your task get
Pick what the change touches — the label, the route and the reasoning appear on the right
Six zones that are never low-risk
Regardless of what Loops scores, and regardless of how small the change looks
Data and schemas
Migrations and any data schema change
Access
Authentication, authorisation, roles, permissions
Money
Payment flows and billing
Data deletion
Deleting or bulk-modifying data
Infrastructure
Secrets, environment variables, CI/CD config
Contracts
API contract changes between repositories
A task's path from client to production
Press Play to watch the task move. Switch on "Gate fails" and the track hands it back to a human
Four conditions the track cannot run without
Both gates say APPROVE
Any CHANGES REQUESTED from AI Review or FAIL from AI QA immediately moves the task to a human gate. There is no partial pass
Maximum 5 self-fix iterations
Cyrus gets five attempts to address AI Review findings. The next failure escalates to a human. The cap catches tasks where the problem is the brief, not the code
Guard window
Deploys happen only during the team's working hours. A PR ready at 23:40 waits until morning — so there is someone to respond to an incident
Automatic rollback trigger
An error spike in Sentry or a failing health check rolls the release back and opens an incident task. The rollback decision does not wait for a human
When we deploy, and what happens when it breaks
The client writes the problem. The pipeline cuts it by repository
Cyrus works within one repository per task. Cross-repo work is therefore decomposed into sub-issues carrying repo:* labels — the client never has to think about repositories
| Label | Repository | Class |
|---|---|---|
repo:marketing-site | Marketing website (static) | client-editable |
repo:shopify-plugin | Shopify plugin + backend API | restricted |
repo:frontend-app | Frontend app (dashboard) | guarded |
repo:demo-shopify-plugin | Demo shopify plugin | guarded |
repo:demo-frontend | Demo frontend | guarded |
The one human gate that is never delegated to AI
Cyrus in two different repos shares no context. Without a fixed contract it will generate two incompatible halves. Switch the scenario:
Where we can go faster, and how a parent closes
demo Demo ships faster
QA Two-level acceptance
Least privilege, generated together with the pipeline
Access isn't handed out "on request in chat" — it is part of the project configuration
| Resource | Client access | Rationale |
|---|---|---|
| Linear (client project) | Create / comment / read | The primary channel of participation |
risk:* labels | Read only | Risk is decided by the system, not the requester |
| Staging | Full UI access | Verification before and after AI QA |
| Preview deployments | Read | Early inspection of a PR |
| Production | As a product user only | No deployment admin panels |
| GitHub / repositories | Owner; write level is per-repo | The client owns the repos; direct-change boundaries are set per repository |
| CI/CD, infrastructure | No direct access to configuration | Aimeice's area of responsibility, including rollback mechanisms |
| Sentry / telemetry | Digest in Slack | The data may contain PII |
| Project Slack channel | Member | Status and release notifications |
The question isn't ownership — it's whether direct edits are safe
The client owns the repositories. Each repo is assigned a class when the pipeline is generated. Pick a class:
Fast-track only removes the queue for low-risk
Medium and high tasks still hit human gates. Without WIP limits the pipeline simply piles up queues in front of them — and the fast-track gain is eaten by everything else waiting
Limits only on human phases
In Review ≤ 2 per dev · QA ≤ 3 per engineer · Ready to Deploy ≤ 5 per team. AI phases carry no limits
Cap per agent
Cyrus carries at most 3–5 build tasks at once. "Queue 30 tasks overnight" means a review backlog and shallow gates
Aging alert instead of standup
A task sitting over 24h in front of a gate pings the gate owner in Slack. The queue is a metric you can see
What we measure on fast-track
A weekly metrics review is an Aimeice commitment under this policy. You see the same numbers we do
What we guarantee, and what the client takes on
Aimeice Tech
Client
The policy carries its own safeguard
Fast-track is not a permanent arrangement. Drag the slider — it is the monthly rollback rate:
Quarterly review
The policy is reviewed every quarter regardless of metrics. The risk:low criteria narrow or widen based on actual data
Review after an incident
Every production incident caused by a fast-track release triggers a retro and a policy review. No exceptions, no "it was a one-off"
Eight rules holding it all together
Phases are the mechanics. Principles are the reasons. They separate a system from "we sprinkled AI everywhere"
Spec-first
The spec matters more than the code. DoR and acceptance criteria are approved before work starts. A vague spec means AI filling gaps with guesses about a business it doesn't know
AGENTS.md in every repo
One file with conventions, stack and do/don't for the agent. A de-facto standard in 2026. Cheap, and it raises quality immediately
Route by risk, not by effort
A one-line change in billing is high-risk. Auth / payments / migrations / PII always go to a human, however few the lines
AI reviews, but never itself
Generator and reviewer are different agents with different lenses. The same agent carries the same blind spots
Eight rules holding it all together
Plus the one clients value most: you see the process, not only the result
Gates don't disappear — they change hands
On fast-track, review and QA are executed by AI, but they remain mandatory. A skipped gate isn't a fast track, it's the absence of process
Least privilege by repo class
Access is decided not by job title or ownership, but by "what happens to production if this goes wrong here"
Every auto-release has an address to roll back to
Rollback trigger, tag of the last stable release, incident task. Automation without a rollback isn't automation
Transparency by default
AI gate results, deploys and metrics are visible to the client in Linear and Slack in real time. You watch the task move through the pipeline
A typical services company vs Aimeice
This is not "the same process, but faster". It is a different operating model
Week 1 — boundaries, access, intake
Goal: the client can file a task, and the system knows what to do with it
repo:* label. Branch protection on guarded, direct changes blocked on restrictedrisk:* labels read-only for the client. Any extension is recorded in the pipeline READMEWeek 2 — the first auto-release
Goal: a client task runs the track end to end, and fast-track metrics start accumulating
You're inside.
Not in the queue.
We don't sell developer hours. We sell a measurable delivery cycle in which the client is a participant, not a customer in a queue.
Ready to build together?
Let's work out which of your repositories could go fast-track this month