The Gated-Lane Model
A lane is the sanctioned path for a kind of work. It defines the prerequisites, owners, required evidence and exits that apply. It is not a synonym for a command name or a row of checkboxes. A command can enter the lane, but much of the work is routed automatically through skills and bounded agent roles.
A gate is a condition for leaving a phase. It prevents later work from assuming something that has not been established. Recorded criteria describe agreed behavior; a failing regression establishes a defect that the correction must address; fresh verification establishes what the current implementation does. None substitutes for the others.
Choose a lane from the work, not its size
Section titled “Choose a lane from the work, not its size”New observable behavior belongs to feature. A maintained specification or qualifying mini-spec establishes the behavioral obligations before implementation. The full path includes planning and coordinated execution; a small lane trims artifact work only when all of its classification conditions hold.
A confirmed defect belongs to fix. The regression must reproduce the reported behavior and fail for the right reason before the minimum correction. An unknown cause starts with debug: Investigate and fix explains the evidence and named investigation exits.
A behavior-preserving change belongs to refactor. Its primary obligation is parity through preserved behavioral assertions from its measured baseline, including characterization backfill. Necessary import or symbol-reference changes retain the same oracle. Changing an expected result to accommodate new behavior is not evidence of preservation. The refactor contract governs that route rather than the feature diagram below.
Maintenance uses the relevant maintenance contract. Documentation, dependency changes and reverts have different review needs even when grouped under a lighter chore entry. A dependency change still needs its applicable dependency review; the word “chore” does not waive supply-chain constraints.
An exploratory spike ends in findings. It does not become production work by being on a branch. The spike entry owns its disposable scope and non-PR boundary. Investigation, initialization and read-only review can also end without a PR. “Every change lands through a PR” does not mean every invocation creates one.
The number of changed lines does not choose the lane. One line can alter a public contract; hundreds of generated documentation lines can preserve behavior. Start from what must change and what must remain true.
Follow the full feature path
Section titled “Follow the full feature path”The map follows a maintained specification through useful task scopes and authorized delivery. The implementation owner chooses direct implementation or valuable delegation. Conditional author and reviewer roles run only when useful or required; rows identify roles, not mandatory staffing.
Follow the work, not a catalog
A feature request becomes a reviewed pull request
The requested outcome authorizes scoped feature work. Maintain its spec and plan, follow actual dependencies, implement directly or delegate useful units, and report observed checks. Real user stops, host permissions, security controls and delivery authority remain effective.
Rows identify roles. Gold commands enter or define a procedure; blue skills coordinate work; green agents perform bounded roles. Arrows cross rows in execution order. A dashed arrow reuses a procedure rather than calling its entry again. Dashed nodes are conditional roles selected for the work.
Chapter 1 / 4
Define the change
What behavior is being agreed to?
Link to this chapter- command
/ca:feature
Resolve existing work before classifying a new request. Resume its actual unfinished step and preserve the selected representation.
Result: The selected lane, current scope and exact artifact route.
full lane → New full-lane work enters brainstorming.
Source for step 1 - skill
brainstorming
Refine the agreed outcome into observable criteria and exclusions. Ask about consequential unresolved choices while retaining decisions already made.
Result: A saved specification with criteria and actual open decisions.
criteria → Return the selected specification and actual open decisions directly to planning.
Source for step 2 - skill
writing-plans
Describe coherent tasks, relevant paths, actual dependencies and checks under existing authorization. Maintain in-scope methods with a reason and preserve source identity.
Result: A useful working plan; missing requirements and structural failures remain explicit.
ready plan → The coordinator receives the maintained plan and selects useful authorized work.
Source for step 3 - skill
executing-plans
Select meaningful work using actual task dependencies. Preserve blocked members and authored scope while allowing independent work to continue.
Result: A bounded task scope handed to the implementation owner.
Source for step 4
Before continuing: A maintained specification and linked plan with observable criteria, actual dependencies and unresolved choices kept visible.
Continuations, returns and repeat paths
- Select useful scope. The coordinator hands the named scope to the implementation owner and resumes from its actual results. Next: subagent-driven-development: select. Owning contract
Chapter 2 / 4
Build and verify each task
Who writes, and what proves this task?
Link to this chapter- skill
subagent-driven-development: select
Inspect the selected scope, criteria, actual dependencies and current work. Engine eligibility is advisory; inspect outstanding workers before redispatch after interruption.
Result: Useful next work with the relevant requirements and checks.
implement → Implement directly or assign a useful bounded unit; delegation is conditional.
Source for step 5 - agent · if applicable
Optional backend, frontend or infrastructure author
Choose direct implementation for focused work. Delegate when isolation, parallel work or expertise helps, supplying bounded relevant context. A delivery receipt does not grant execution permission.
Result: Scoped work performed directly or by an appropriate author.
verify approach → The implementer follows the verification approach suited to the assigned work.
Source for step 6 - skill
tdd: select and prove the approach
Use genuine regression RED/GREEN for confirmed fixes, criterion-focused feature checks and passing characterization baselines for refactors. Non-executable changes use relevant validation.
Result: Observed evidence and pending checks returned to the caller.
Inspect all six TDD phases
- Obligations: map required claims to meaningful proving checks.
- Baseline: observe target RED for a fix or passing characterization before refactoring; prefer test-first features.
- Implement: run the scoped proving checks and affected existing contracts, preserving assertions.
- Verify obligations: keep missing or failed evidence visible and rerun affected checks.
- Coverage: meet the declared profile and critical-path requirements; report unmeasured scope.
- Lint and handoff: run applicable quality tools and return actual commands, results and limitations.
return → Return actual results so the caller can assess criteria, source applicability and remaining work.
Source for step 7 - skill
subagent-driven-development: verify
Compare the result with criteria and run applicable checks. Record commands, working directories, outcomes and limitations. Reuse evidence only while its checked source and inputs remain applicable.
Result: Observed verification and pending checks; task status is not test evidence.
Source for step 8
Before continuing: Implemented work with actual check results and pending verification, returned to the caller.
Continuations, returns and repeat paths
- Continue independent work. Choose the next task by actual dependencies; an unrelated failure does not prohibit useful authorized work. Next: subagent-driven-development: select. Owning contract
- Review where warranted. Use applicable independent review for the combined change when risk or policy calls for it. Next: Risk-selected reviewers. Owning contract
- Record scoped progress. Ordinary work can record implementation progress without manufacturing an independent review receipt. Next: subagent-driven-development: record progress. Owning contract
- Repair affected checks. An unexplained failure or missing requirement remains outstanding. Repair the work and rerun the appropriate checks without weakening assertions. Next: tdd: select and prove the approach. Owning contract
Chapter 3 / 4
Review and report progress
What evidence and next work return to the caller?
Link to this chapter- agent · if applicable
Risk-selected reviewers
Review the combined relevant diff when risk or policy requires it. Use specialist reviewers for applicable security, dependency or migration concerns and avoid duplicate per-task reviewer cascades.
Result: Applicable findings against the actual reviewed source.
findings → When independent reviewers are dispatched, aggregate their complete findings and unit outcomes.
Source for step 9 - agent · if applicable
finding-triage
Route a dispatched review batch through finding triage and verdict aggregation. Preserve blockers, incomplete units and out-of-scope findings without inventing a successful review.
Result: One triaged verdict with its actual evidence limits.
results → Return applicable review results; implementation status must not conceal failures or missing checks.
Source for step 10 - skill
subagent-driven-development: record progress
Use the selected writer to record completed implementation. HTML accept-scope can record DONE without a receipt; it cannot clear pending or blocked members. Keep verification and independent acceptance distinct.
Result: Completed implementation, actual checks and unresolved issues returned to the caller.
to caller → The scoped invocation returns to its coordinator with work and evidence, not directly to commit.
Source for step 11 - skill
executing-plans: report and continue
Report changes, checks and next work, then continue within existing authorization. Honor a user-requested pause, consequential decision, or actual host/security restriction for the affected work.
Result: The next authorized scope or an honest delivery handoff.
Source for step 12
Before continuing: Current implementation progress, applicable review and check results, and the next authorized work.
Continuations, returns and repeat paths
- Correct blocking findings. Resolve affected findings within existing scope, rerun relevant checks and refresh changed review conclusions. Next: Optional backend, frontend or infrastructure author. Owning contract
- Next authorized scope. Continue normal authorized work while preserving real dependencies and any explicit user-requested pause. Next: subagent-driven-development: select. Owning contract
- Authorized delivery. Hand current scope, actual check results and remaining work to the commit owner only when committing is authorized. Next: commit-gate. Owning contract
Chapter 4 / 4
Commit and open the PR
Which action is actually authorized?
Link to this chapter- skill
commit-gate
Use the commit owner only when committing is authorized. It checks the selected staged work, applicable tests, secrets and specialized controls, with fresh behavioral proof.
Result: A selectively staged commit and observed gate results.
committed → The branch-finishing owner checks current-head readiness and the selected delivery action.
Source for step 13 - skill
finishing-a-development-branch
Retain an existing open-PR choice. Ask for branch disposition only if it is unclear. Merge and discard require their own explicit authorization and applicable evidence.
Result: The selected terminal action supported by current branch state.
reuse → Execute the PR contract in place; do not re-invoke its command.
Source for step 14 - command
/ca:pr procedure, reused by finishing
Finishing executes the PR procedure in place; the command is not re-invoked. For a committed branch, verify the explicit base-to-HEAD subject, including secrets and specialized checks, without creating another commit.
Result: Current-head readiness and required review for the authorized PR.
review → PR creation includes its own path-selected review and verdict.
Source for step 15 - agent
PR reviewers, finding-triage and verdict-aggregator
Apply the PR path matrix and review funnel, including security review for CI/deployment/infrastructure changes. Resolve blockers and report the PR URL, current head and observed checks.
Result: An open PR. Exact-head hosted CI and explicit merge authority still govern integration.
Source for step 16
Before continuing: An authorized open PR with its current source and observed checks. Merge and publication remain separate actions.
Continuations, returns and repeat paths
An open PR, its source identity and observed check state. Merging and publishing remain separate decisions.
executing-plans passes a task scope to subagent-driven-development. The implementation owner
returns completed work, observed checks and remaining issues. It does not jump directly to commit
just because a batch finished. The coordinator continues authorized work unless an explicit user
pause, consequential unresolved choice or actual host boundary prevents the affected action.
How many gates, concretely
Section titled “How many gates, concretely”A phase count is less useful than its condition. TDD selects the verification approach, establishes its baseline, implements and checks, verifies obligations, measures required coverage, then runs lint and hands off evidence. Confirmed fixes require target RED/GREEN; features use criterion-focused checks and refactors preserve passing characterization baselines. The test-first concept explains what those observations prove.
The commit gate has nine numbered phases covering permission, branch, classification, verification, behavioral proof, diff review, selective staging, message and commit. Its conditional provenance auto-heal step is not a separate tenth ordinary phase. A prior passing result cannot certify a later staged diff merely because both used the same branch name.
The HTML task model distinguishes progress from verification. REVIEW and DONE record
implementation progress; check results establish what passed. Eligibility provides scheduling
advice. Ordinary authorized progress does not require acceptance receipts. Existing Markdown pairs
retain one ledger and their original format; a diagram does not authorize conversion.
STOP, BLOCK and human authority
Section titled “STOP, BLOCK and human authority”STOP respects an actual boundary. An explicitly requested review pause or a consequential unanswered product choice can stop affected work. Routine progress reports do not create another approval request; independent authorized tasks may continue.
BLOCK refuses to advance until its condition is satisfied. A failing regression, incomplete requirement or unresolved permission cannot become a pass through more confident prose. Repairing the actual problem and rerunning the check is different from requesting a bypass.
A hard decision boundary can require explicit human authority even during a sprint. Security, irreversible operations, overrides and merge decisions retain their applicable rules. Other failures may have a supported correction or recovery path. It is inaccurate to treat every BLOCK as something only an override can clear, or every user “yes” as enough to clear a mechanical failure.
Where a bypass is permitted, the override procedure owns its immediate scope and audit entry. H-18 activation protection has no in-session override path. A diagram must not erase that exception by drawing a universal “continue anyway” arrow.
Mandatory routing at commit time
Section titled “Mandatory routing at commit time”Certain changed surfaces bring their own review or marker requirements. Crypto/secret handling uses its digest-bound marker contract. Migrations have a separate required review marker. CI and deployment changes route security review, while their post-write reminders are advisory. These are different enforcement mechanisms, not identical colored boxes.
Use Hook Gates to inspect the exact condition and effect. A mandatory procedure in orchestration prose and a hook that mechanically blocks a tool event have different proof boundaries. The enforcement model explains the distinction.
The terminal lane
Section titled “The terminal lane”Finishing retains an already selected action and asks for branch disposition only when it is unclear. This map illustrates Open a PR. It verifies a committed branch against the explicit base-to-HEAD diff; authorized uncommitted work uses the commit owner. A separate authorized merge still requires exact-head hosted checks. Sprint autonomy ends at an open PR.
Finishing reuses the PR command’s documented procedure in place. It expressly does not call that
entry again. This is why a chart showing an unconditional /pr call after every internal skill can
misrepresent the actual route. The delivery guide describes the human
handoff and subsequent cleanup.
Check your understanding
Section titled “Check your understanding”For one real task, identify the behavior being changed or preserved, the lane that owns it, its first required evidence and the next owner. Then identify the relevant alternate exit: a correction, a missing decision, a supported resume, or findings without implementation.
Compare those answers with the owning command and skill references. A successful explanation predicts both the normal path and where that path must stop. Use the feature guide to perform the work, rather than treating this explanatory map as a runnable procedure or an execution receipt.
The decision-boundary illustration and commit-phase diagram are supplementary views. Neither makes every failed check a user-decision case or authorizes a universal override.
