Add engineering constraints to RDD reviews

AGENTS.md

@@ -11,10 +11,12 @@ serialization shapes; it does not contain a project's live delivery state.
   completion, records, and reconciliation.
 - [`skills/`](skills/) contains focused procedures that apply the process.
 - [`file-state/`](file-state/) contains the canonical serialization shapes for
-  Epic, requirement, gate, work-selection, and backlog/gap records.
-- Project instructions own only project-specific rules such as architecture,
-  repository topology, commands, environments, and test gates. They reference
-  rather than redefine the process.
+  Epic, requirement, engineering-constraint, gate, work-selection, and
+  backlog/gap records.
+- Project instructions own project-specific sources such as architecture,
+  repository topology, commands, environments, and test gates. EC records cite
+  those sources and bind their rules into delivery; neither may redefine the
+  process.
 - `CLAUDE.md` files are compatibility pointers; they do not override these
   instructions.
 
@@ -34,10 +36,12 @@ Before planning, changing, reviewing, or delivering product work:
    process pass; use `skills/rdd-verify/SKILL.md` for reverse-engineered
    `PENDING_VERIFICATION` rows, and `skills/rdd-reverse-engineer/SKILL.md` to
    adopt a codebase that has no requirement corpus yet;
+   `skills/rdd-engineering-check/SKILL.md` is the focused EC evaluator invoked
+   by cold and completion review, not a phase;
    `skills/rdd-audit/SKILL.md` is a shared utility other passes invoke, not a
    phase;
 4. read the relevant product sources, requirement records, optional epic, and
-   active work-selection record.
+   active work-selection and engineering-constraint records.
 
 ## Binding process
 

PROCESS.md

@@ -17,11 +17,15 @@ UPPER (UR): UR -- contains --> acceptance scenario -> TEST_CASE -> TEST_RESULT
 
 LOWER (SR): SR -> CODE -> TEST_CASE -> TEST_RESULT
 
+ENGINEERING: selected scope -> applicable ACTIVE EC -> engineering trace gate
+
 EPIC: PROPOSED -[HUMAN]-> TODO -> IN_PROGRESS -> IN_REVIEW -[HUMAN]-> DONE
 
 UR/SR: DERIVED -[HUMAN]-> PROPOSED -[HUMAN]-> TODO -> IN_PROGRESS -> IN_REVIEW -[HUMAN]-> DONE
 UR/SR: DERIVED -[HUMAN]-> PENDING_VERIFICATION -[HUMAN]-> TODO -> IN_PROGRESS -> IN_REVIEW -[HUMAN]-> DONE
 
+EC: PROPOSED -[HUMAN]-> ACTIVE -[HUMAN]-> SUPERSEDED | RETIRED
+
 TRACE: PENDING -> PASS | FAIL; PASS | FAIL -> STALE -> PASS | FAIL
 
 HUMAN: DRAFT -> OPEN -> ANSWERED -> CLOSED
@@ -34,6 +38,11 @@ component, contract, or integration boundary. Both are red-first. They are
 evidence classes owned by different requirement types, not two arms of one
 requirement.
 
+An engineering constraint (`EC`) is a persistent architectural, quality, or
+engineering rule. It is not product behavior and does not use the UR/SR work
+lifecycle. Applicable active ECs are evaluated independently by an engineering
+trace gate during cold review and again against the delivered revision.
+
 ## Authority
 
 Humans decide product intent, scope, architecture, acceptance, priority,
@@ -49,6 +58,7 @@ be established from authoritative records, code, tests, or runtime evidence.
 | `TEST:<path>:<name>` | Stable test-case identity |
 | `RUN:<command-or-report>` | Observed test or runtime result |
 | `EPIC:<path>#<section>` | Existing Epic record |
+| `EC:<id>` | Active engineering constraint in the authoritative process store |
 
 Missing support is an open question. Conflicting support remains a conflict
 until a human resolves it. Code proves existing behavior, not intended behavior.
@@ -72,6 +82,7 @@ for an applied change belongs to the change itself and its gate records.
 | `CODE` | Implementing files, symbols, revisions, branches, and changes |
 | `TEST_CASE` | Stable identity, targeted UR scenario or SR clause, expected observation |
 | `TEST_RESULT` | Outcome, RED/passing role, validity, command/report, environment, and tested fingerprint |
+| `EC` | Persistent architecture, quality, or engineering constraint; proposal evidence, authority, explicit scope, rationale, lifecycle, and verification method |
 
 Acceptance scenarios are UR content, not separate lifecycle records. Split an
 SR that contains independently implementable behaviors. Projects may retain
@@ -95,6 +106,20 @@ A test covering multiple clauses must identify every target and assertion. A
 UR-to-SR relation makes the SR part of the UR trace; it does not make UR upper
 evidence part of the SR lower trace.
 
+Engineering conformance is a separate trace. For every selected scope, resolve
+the complete flat set of `ACTIVE` ECs whose declared scope matches the affected
+repository, language, service, domain, or path. ECs are not inherited through
+profiles and are never copied onto URs or SRs. Resolve and fingerprint this set
+after reconnaissance establishes the affected surface; initial resolution is
+planning progress, not a change to the frozen work-selection fingerprint.
+
+Engineering checks produce separate trace-gate results for the planning packet,
+the pre-delivery candidate, and the delivered revision. Each result records the
+exact applicable EC set and target fingerprint, and every member must pass its
+declared verification. Ambiguous applicability, a missing verification method,
+or an unmet active EC fails the trace. A proposed, superseded, or retired EC does
+not apply.
+
 ## Lifecycle states
 
 UR and SR use the same status vocabulary.
@@ -125,6 +150,26 @@ lifecycle. Evidence conclusions are not completion states:
 - `LOWER_VERIFIED`: current lower evidence for an SR.
 - `UPPER_VALIDATED`: current upper evidence for UR acceptance content.
 
+### Engineering-constraint states
+
+| Status | Meaning |
+|---|---|
+| `PROPOSED` | Constraint statement, proposal evidence, scope, rationale, and verification method are being prepared for human activation |
+| `ACTIVE` | Human-approved constraint included whenever its declared scope applies |
+| `SUPERSEDED` | Terminal constraint version replaced by a named successor |
+| `RETIRED` | Terminal constraint removed by an attributable human decision |
+
+Activating, superseding, or retiring an EC is a human decision. Code can prove
+an observed convention but cannot make it normative. Changing an active EC's
+statement, scope, or verification method creates a successor rather than
+silently changing the approved constraint. EC activation is prospective from
+the effective release or store revision recorded by its activation gate. After
+the initial post-reconnaissance resolution, a changed affected surface or
+applicable set makes a nonterminal selection's engineering, cold-review, and
+entry gates stale and returns it to planning. It does not reopen a `DONE` scope
+delivered before that effective point unless the activation decision explicitly
+names it for remediation.
+
 ### Derived requirement hold
 
 While a requirement is `DERIVED`:
@@ -172,6 +217,8 @@ not a gate answer.
 | Transition | Required trace `PASS` before human input |
 |---|---|
 | Requirement `DERIVED -> PROPOSED/PENDING_VERIFICATION/OBSOLETE` | Candidate packet and exact confirmation scope complete |
+| EC `PROPOSED -> ACTIVE` | Statement, proposal evidence, exact scope, effective point, rationale, verification method, and impact are complete |
+| EC `ACTIVE -> SUPERSEDED/RETIRED` | Successor or retirement effect and affected scope are complete |
 | Requirement `PROPOSED/PENDING_VERIFICATION -> TODO` | Its Entry packet is complete at the exact fingerprint |
 | 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 |
@@ -260,7 +307,11 @@ The fingerprinted packet must contain:
 
 Reconnaissance cites `DOC:`, `CODE:`, and `TEST:` sources. Generated context is
 navigation only. Material revision drift makes the packet and its dependent
-reviews stale.
+reviews stale. Once reconnaissance establishes the affected repository,
+language, service, domain, and path surface, record the exact applicable active
+EC ids and their set fingerprint in the work selection. This first resolution
+does not alter the frozen selection fingerprint; changing the resolved surface
+or EC set afterwards returns the packet to planning.
 
 Cold review runs from a context independent of packet authoring and audits the
 trace, scope, technical surface, changed flow, contracts, data, compatibility,
@@ -271,6 +322,12 @@ in-scope deferred correctness, security, data-loss, contract, traceability, or
 testability findings fail the cold-review trace gate. Technical review cannot
 grant entry approval.
 
+Cold review invokes `rdd-engineering-check` rather than embedding EC evaluation.
+A current engineering trace `PASS` at the planning fingerprint is a prerequisite
+for cold-review `PASS`. Engineering findings join the cold-review finding list,
+but the broader technical review remains responsible for risks not expressed as
+ECs; the flat EC set is not presumed complete.
+
 Entry review evaluates the complete packet at its exact fingerprint. Only a
 current entry trace `PASS` may open the human entry gate. Do not create or
 change tests or implementation until every selected item is `TODO`.
@@ -302,6 +359,15 @@ Before each phase, reconcile answered gates and state, then select the earliest
 unmet prerequisite. A focused skill's exit is a handoff, not completion of the
 full loop.
 
+`rdd-engineering-check` is a shared utility, not a phase. Cold review invokes it
+against the planning fingerprint. Completion review invokes it first against
+the candidate code before integration, then records a separate result against
+the delivered fingerprint. It evaluates EC conformance and records engineering
+trace gates; it does not perform the rest of either review or change lifecycle
+state. Approved implementation changes do not stale the planning result because
+code is not an input to that result; they require the separate candidate and
+delivered results.
+
 ### AI TDD inner loop
 
 After human entry places the selected scope in `TODO`, the AI owns the automatic
@@ -397,15 +463,18 @@ Supplemental evidence causes no demotion. Re-verification may restore
 completion gate. Material approved-scope changes stale entry approval and send
 work back to planning.
 
-A 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.
+Delivery may proceed only after the pre-delivery candidate has a current passing
+engineering trace. A 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, the separate delivered
+engineering trace is current and passing, and gaps/deferrals/decisions are
+disclosed.
 
 | Item | `DONE` predicate after human acceptance |
 |---|---|
-| SR | Its lower trace is delivered, current, and reconciled |
-| UR | All scenarios have current upper evidence; every required SR has a complete lower trace; result is delivered and reconciled |
-| Epic | Every member is `DONE`; applicable member and declared Epic gates pass; Epic scope is delivered and reconciled |
+| SR | Its lower trace is delivered, current, and reconciled; the delivered engineering trace passes |
+| UR | All scenarios have current upper evidence; every required SR has a complete lower trace; result is delivered and reconciled; the delivered engineering trace passes |
+| Epic | Every member is `DONE`; applicable member, Epic, and delivered engineering gates pass; Epic scope is delivered and reconciled |
 
 Completing one item never advances an optional related item unless that item
 independently satisfies its predicate and is named in the human gate.
@@ -431,22 +500,24 @@ currency is checkable per file.
 file-state/
   EPICS.md
   REQUIREMENTS.md
+  ENGINEERING-CONSTRAINTS.md
   GATES.md
   WORK-SELECTION.md
   BACKLOG.md
 ```
 
 `EPICS.md` stores optional grouping records. `REQUIREMENTS.md` stores URs, SRs,
-declared relations, and trace references. `GATES.md` stores every trace and
-human gate record. `WORK-SELECTION.md` stores the frozen scope, suspended
-selections, and selection history. `BACKLOG.md` stores unrouted triage items
-and gap records. Derived queues and progress views — including the pending
-human-decision projection — are regenerated, not backed up separately.
+declared relations, and trace references. `ENGINEERING-CONSTRAINTS.md` stores
+the flat EC set and its lifecycle. `GATES.md` stores every trace and human gate
+record. `WORK-SELECTION.md` stores the frozen scope, suspended selections, and
+selection history. `BACKLOG.md` stores unrouted triage items and gap records.
+Derived queues and progress views — including the pending human-decision
+projection — are regenerated, not backed up separately.
 
 | Concern | Authority |
 |---|---|
 | Product/domain/architecture/contracts | Product documents and schemas |
-| Epic, requirement, relation, gate, decision, release, and work-selection state | Authoritative process store |
+| Epic, requirement, relation, EC, gate, decision, release, and work-selection state | Authoritative process store |
 | Code, test cases, and results | Implementation repository plus exact evidence references |
 | Aggregate progress and human queues | Generated projections; never lifecycle authority |
 
@@ -470,6 +541,7 @@ After every transition, update the complete affected graph and run checks for:
 - valid identities/statuses and reciprocal declared relations;
 - stable test identities, revision-pinned validity, and invalidation cascades;
 - exact gate fingerprints and legal gate/state transitions;
+- exact applicable active EC sets and current engineering-trace results;
 - no `TODO` without applied entry approval;
 - no `DONE` without delivered evidence, reconciliation, and applied completion;
 - isolation of `DERIVED` items and candidate links from authoritative scope;
@@ -484,6 +556,7 @@ human decisions.
 |---|---|
 | Inferred possible requirement | `DERIVED` plus confirmation gate; links remain candidate-only |
 | Directly sourced requirement | `PROPOSED` UR or SR |
+| Observed or requested architecture, quality, or engineering rule | `PROPOSED` EC; inactive until its human activation gate closes |
 | Missing human decision or ambiguity | Decision gate; `BLOCKED` only when work cannot proceed |
 | Known future work | `DEFERRED` with reason, owner, and target |
 | Capability/specification gap | Gap linked to affected traces |

README.md

@@ -10,10 +10,13 @@ EPIC -- optionally groups --> UR and/or SR
 UR -> acceptance scenario -> TEST_CASE -> TEST_RESULT
 UR acceptance scenario -- may require --> SR
 SR -> CODE -> TEST_CASE -> TEST_RESULT
+selected scope -> applicable ACTIVE EC -> engineering trace gate
 
-Each selected trace passes planning, technical review, human entry, red-first
-evidence, implementation, cleanup, verification, delivery, reconciliation,
-and human completion.
+Each selected product trace passes planning, technical review, human entry,
+red-first evidence, implementation, cleanup, verification, delivery,
+reconciliation, and human completion. Its separate engineering trace evaluates
+the applicable flat EC set during cold review, before integration, and at the
+delivered revision.
 ```
 
 Product repositories hold authoritative process records in one selected store,
@@ -43,8 +46,8 @@ apply that model; `file-state/` serializes its records without redefining it.
 | `AGENTS.md` | shared agent policy and canonical entry point |
 | `PROCESS.md` | complete canonical process |
 | `CLAUDE.md` | root compatibility entry required for Claude discovery |
-| `skills/` | full-loop orchestration plus focused procedures for discovery, planning, review, building, triage, completion, and as-built verification; corpus adoption for codebases without requirement records (`rdd-reverse-engineer`); a shared document/citation auditing utility (`rdd-audit`) |
-| `file-state/` | canonical serialization shapes for Epic, requirement, gate, work-selection, and backlog/gap records |
+| `skills/` | full-loop orchestration plus focused procedures for discovery, planning, review, building, triage, completion, and as-built verification; a focused flat-EC evaluator (`rdd-engineering-check`); corpus adoption for codebases without requirement records (`rdd-reverse-engineer`); a shared document/citation auditing utility (`rdd-audit`) |
+| `file-state/` | canonical serialization shapes for Epic, requirement, engineering-constraint, gate, work-selection, and backlog/gap records |
 
 ## Distribution
 
@@ -68,8 +71,8 @@ human gates with current passing prerequisites. Neither is an authority; see
 ## Process maintenance
 
 Changes to lifecycle, status meanings, trace relationships, gate requirements,
-evidence rules, or record ownership belong in `PROCESS.md`. Validate internal
-links and search the skills and flat-file shapes for competing authority
-statements whenever it changes.
+evidence rules, engineering-constraint semantics, or record ownership belong in
+`PROCESS.md`. Validate internal links and search the skills and flat-file shapes
+for competing authority statements whenever it changes.
 
 License: MIT.

file-state/BACKLOG.md

@@ -24,8 +24,8 @@ requirement and does not belong here.
 - **Raised by / at:** «USER:/CODE:/RUN:/TEST: source» / «timestamp»
 - **Observed:** «what was seen, not what it implies»
 - **Why unrouted:** «unclear owner, cross-cutting, or awaiting a decision»
-- **Candidate route:** «PROPOSED UR/SR, DERIVED, gap, conflict, or decision gate»
-- **Affected items:** «EPIC/UR/SR ids, or none known»
+- **Candidate route:** «PROPOSED UR/SR, PROPOSED EC, DERIVED, gap, conflict, or decision gate»
+- **Affected items:** «EPIC/UR/SR/EC ids, or none known»
 - **Disposition:** OPEN / ROUTED to «id» / REJECTED with «source»
 
 ## Gap records

file-state/ENGINEERING-CONSTRAINTS.md

@@ -0,0 +1,33 @@
+# Engineering-constraint flat-file state
+
+> Canonical EC serialization for the authoritative process store. `PROCESS.md`
+> defines EC ownership, lifecycle, applicability, and engineering trace rules.
+> A store-backed repository materializes this file from the store; a file-backed
+> repository versions it as the store. Never both.
+
+- **Snapshot at:** «timestamp»
+- **Source store/revision:** «database revision or repository SHA»
+- **Context / release:** «scope»
+
+This is one flat set. There are no profiles, inheritance rules, or implicit
+service defaults. Every constraint declares its own applicability.
+
+## EC-«AREA»-«NNN» — «Title»
+
+- **Kind:** ARCHITECTURE / QUALITY / ENGINEERING
+- **Status:** PROPOSED / ACTIVE / SUPERSEDED / RETIRED
+- **Statement:** «one normative rule»
+- **Proposal evidence:** «USER:/DOC:/CODE:/TEST:/RUN: observations supporting the proposal»
+- **Authority:** «applied human activation gate and optional normative DOC: source; none while unapproved»
+- **Rationale:** «why the constraint exists and the consequence it prevents»
+- **Scope:** «global, or explicit repository/language/service/domain/path targets»
+- **Effective from:** «release or store revision established by the activation gate»
+- **Owner:** «person or team responsible for the rule»
+- **Verification:** «deterministic command/check, architecture test, static analysis, or exact review observation»
+- **Activation/retirement gates:** «GATES.md gate ids»
+- **Supersedes / superseded by:** «EC id or none»
+- **Notes:** «ambiguities or none»
+
+Code may support a proposal as evidence of an observed convention, but only an
+attributable human source and applied activation gate make an EC `ACTIVE`.
+Changing an active statement, scope, or verification method creates a successor.