feat(process): a small-change lane that scales review and gates to the change

PROCESS.md

@@ -244,6 +244,8 @@ not a gate answer.
 | Source-scoped baseline authorization | Bound system/store, current corpus and exact source/document inventory reviewed; allowed baseline publication made explicit |
 | Source-scoped baseline requirement `PENDING_VERIFICATION -> DONE` | Complete exact current as-built verification and separate repository integration proof; one dedicated reviewed human acceptance |
 | Requirement `PROPOSED/PENDING_VERIFICATION -> TODO` | Its Entry packet is complete at the exact fingerprint |
+| Lane authorization for a system | The classes, excluded areas, who may apply it, expiry and daily cap are explicit |
+| Small change `PROPOSED -> TODO` | Its narrow independent pass is `PASS`, it is eligible, and a current lane authorization covers its class and cap; the entry is recorded as an application of that authorization, attributed to the human who answered it |
 | Epic `PROPOSED -> TODO` | Its Entry packet and every selected member's entry trace are complete |
 | Requirement `IN_REVIEW -> DONE` | Its completion predicate is satisfied at the delivered fingerprint |
 | Epic `IN_REVIEW -> DONE` | Every member is already `DONE` or named and completion-eligible in the same gate; the Epic completion predicate is satisfied |
@@ -368,6 +370,7 @@ failure.
 |---|---|---|
 | Epic | Multiple requirements form one human-readable change, or shared product/architecture/contract/data decisions are required | Exact member UR/SR set; membership is grouping, not ancestry |
 | Single SR | Exactly one independently verifiable system behavior changes | Authoritative SR source; Epic and UR relations optional |
+| Small change | One SR changes one bounded behavior, the change meets the lane's eligibility, and a current lane authorization covers its class | Authoritative SR source; the lane authorization it applies; UR relation optional |
 | Named UR/SR set | Candidate confirmation or source-scoped baseline verification or acceptance | Exact named requirements and applicable declared dependencies; no Epic required |
 | Source inventory | Reverse-engineering before requirement IDs exist | Exact repository/file and document revisions, corpus fingerprint, derivation mode, and source authorization; publication receipts identify the resulting requirements |
 
@@ -388,6 +391,36 @@ Normal delivery selection requires exactly one active release with a `USER:`
 source. Candidate confirmation and source-scoped baseline work do not select a
 delivery release and do not require one to be active.
 
+### Small-change lane
+
+The small-change lane scales review and gates to the size of the change; it
+keeps every invariant of the loop. A change is eligible only when all of these
+hold, checked by the store and the CLI rather than asserted by an agent:
+
+- exactly one SR changes and no other requirement changes status;
+- its change boundary names at most five non-test source files in one
+  repository (tests are not counted — red-first adds them);
+- it touches none of: security, authentication, authorization, or the
+  process's own guards and permissions; migrations, persisted schema or tenant
+  data access; public API routes, response shapes, or CLI verbs and flags;
+  model prompts or anything that calls a model or runs a background job;
+  billing; and any area the lane authorization excludes;
+- its class is one the current lane authorization covers. The classes are: a
+  defect with a diagnosed failing test; wording or copy; a presentation-only
+  change inside one view or one library component; a patch-version dependency
+  update with the suite passing. New features are never small changes.
+
+A lane authorization is a strict human gate answered once for a system by a
+workspace admin or a platform superuser. It names the classes it covers, any
+further excluded areas, who may apply it, its expiry (at most 30 days; renewed
+by a successor gate), and a daily cap. It can be withdrawn at any time; work
+already entered finishes, nothing new enters. Every application of it is
+visible in the authorizing human's feed.
+
+A change that stops being eligible — a finding, a wider boundary, an excluded
+area — leaves the lane for single-SR scope with its full packet and review. It
+is never forced through.
+
 ## Planning and readiness
 
 Planning consists of packet authoring, independent cold review, and entry
@@ -397,6 +430,12 @@ Packet depth is proportional to the selected scope — a single-SR packet may
 satisfy an item in a sentence where an Epic needs pages — but no packet item
 may be omitted. Include the information a builder or gate needs to assess the
 change; document length does not determine requirement scope.
+A small change's packet is its SR record: statement and source, change
+boundary (files, and what must not change), RED plan (the failing test and why
+it fails today), and lane class; together they satisfy the packet items. It
+carries no state inventory — the lane's excluded areas keep persisted and
+shared state out of it — and its ledger search covers the files its boundary
+names.
 
 ### Entry packet
 
@@ -439,6 +478,7 @@ entry review also requires the cold-review verdict. Missing required state
 analysis or an unresolved risk to an acceptance criterion is a finding. Read a
 stated limit, timeout, or constant at the call site that applies it, including the
 conditions that select its value.
+A small change's SR record is its complete packet.
 
 A RED strategy names, for each case requiring new evidence, the planned test
 file, the behavior it asserts, and why it is expected to fail at the revision.
@@ -488,6 +528,9 @@ not itself authorize implementation.
 At most two cold-review rounds run on the selected planning scope. A current
 pass proceeds to entry review. After a second failed round, report the remaining
 material findings to the human; do not start a third round automatically.
+A small change gets one narrow pass from an independent context — the
+boundary against the code, the RED plan, and the eligibility — and no second
+round: a blocking finding sends it out of the lane.
 
 Completion review requires an independent code review of the built change for
 Epic scope. For single-SR scope, obtain one when project gates or the user
@@ -702,6 +745,10 @@ Supplemental evidence causes no demotion. Re-verification may restore
 completion gate. Material approved-scope changes stale entry approval and send
 work back to planning.
 
+One completion human gate may name many small changes — a lane batch — each
+meeting its own predicate below; the human may reject single items, which stay
+`IN_REVIEW`.
+
 A normal completion human gate may open only when named items are `IN_REVIEW`,
 code is delivered, evidence is current at the delivered revision, state is reconciled,
 candidate relations are excluded, and gaps/deferrals/decisions are disclosed.

skills/rdd-cold-review/SKILL.md

@@ -63,10 +63,14 @@ review audits the change the packet proposes, not the packet as a document.
    interfaces, or risks is a note and never blocks; traceability is material
    only when a builder or a gate would act on the wrong citation
    (`PROCESS.md` §Planning and readiness).
-8. Run at most two rounds on the selected planning scope. After a second
+8. For a small change, run one narrow pass: the boundary against the code, the
+   RED plan, and the lane's eligibility. There is no second round — a blocking
+   finding returns `FAIL` with the instruction that the change leaves the lane
+   for single-SR scope.
+9. Run at most two rounds on the selected planning scope. After a second
    failed round, report the remaining material findings to the human;
    do not start a third round automatically.
-9. Return the cold-review trace gate `PASS` only when the material-finding rule
+10. Return the cold-review trace gate `PASS` only when the material-finding rule
    in `PROCESS.md` is satisfied. Otherwise return `FAIL` with exact blockers.
 
 Use `skills/rdd-audit/SKILL.md` to resolve the packet's citations and diff its

skills/rdd-completion-review/SKILL.md

@@ -42,6 +42,9 @@ records, and derived views.
    epic-scoped pass does not stand in for it. Only then make the scoped human
    completion gate `OPEN` and present its brief and linked list of relevant
    working-set files before asking for acceptance, following `PROCESS.md` §Gates.
+   Small changes may be completed together in one lane-batch gate that lists
+   each change with its evidence and review verdict; the human may reject
+   single items, which stay `IN_REVIEW`.
 6. Do not answer the gate for the human. If the authorized human answers,
    record the real actor, role, exact scope, answer, and `USER:` source.
 7. Apply `DONE` only to accepted named entities that independently satisfy the

skills/rdd-entry-review/SKILL.md

@@ -28,6 +28,11 @@ packet, cold-review findings, current gate records, and relevant sources.
    with every referenced decision, correction, or finding stated by its
    substance and not its code. Before presenting, reread the brief as that
    reader and expand any bare identifier or jargon.
+   For a small change there is no per-change human gate: after its narrow pass
+   is `PASS` and its eligibility holds, record its entry as an application of
+   the current lane authorization, which names the human who answered it; a
+   missing, expired, exhausted or non-covering authorization stops here and the
+   change follows the single-SR entry.
 5. Do not answer the gate for the human. If the authorized human answers,
    record the real actor, role, scope, answer, and `USER:` source; apply only
    named transitions and reconcile all affected records. The answer and its

skills/rdd-plan/SKILL.md

@@ -20,9 +20,14 @@ scope, Item ownership, and Planning and readiness sections of `PROCESS.md`.
    and verify each match against its content and declared relations. Carry
    applicable delivered acceptance into the packet. Record surfaces with no
    existing owner without inventing one. A change to existing acceptance
-   is a scope decision for step 6.
-2. Choose epic scope or single-SR scope using `PROCESS.md`. Do not invent epic
-   membership or a UR link to make the graph appear complete.
+   is a scope decision for step 6. For a small change the search covers the
+   files its boundary names.
+2. Choose epic scope, single-SR scope, or the small-change lane using
+   `PROCESS.md`. Do not invent epic membership or a UR link to make the graph
+   appear complete. Take the small-change lane only when the change meets the
+   lane's eligibility and a current lane authorization covers its class; its
+   packet is the SR record's statement, boundary, RED plan and lane class, and
+   nothing more.
 3. Create or update the selected item content: sourced UR outcomes and inline
    scenarios when user behavior is in scope, and thin testable SRs for system
    behavior.

skills/rdd-start/SKILL.md

@@ -110,7 +110,8 @@ These rules bind every subsequent phase in the session:
 ## Route
 
 Select the earliest unmet prerequisite for the frozen scope and hand off to
-its skill: `rdd-discover`, `rdd-plan`, `rdd-cold-review`, `rdd-entry-review`,
+its skill; a change that meets the small-change lane's eligibility under a
+current lane authorization is planned, reviewed and entered through that lane: `rdd-discover`, `rdd-plan`, `rdd-cold-review`, `rdd-entry-review`,
 `rdd-build`, `rdd-verify`, `rdd-completion-review`, or `rdd-deliver` for the
 complete loop. Source-inventory onboarding uses `rdd-reverse-engineer`.