/nw-cross-cutting-invariants

name: nw-cross-cutting-invariants
description: Cross-cutting normative invariants — routing core for the software/model boundary doctrine, gate/construction principles and on-demand knowledge lenses. Cite clause ids; never re-declare.
user-invocable: false
disable-model-invocation: true

Cross-Cutting Invariants — Recomposition Core

Normative rules hold regardless of paradigm and role. `nw-cross-cutting-invariants` is their SHIPPED public home: cite a clause id; do not re-declare it. This core owns global gate/construction doctrine and routes independent KNOWLEDGE lenses; load every applicable lens.

**Reachability precondition.** A pointer works only when the consumer actually loads its referent. Check what the consumer really loads, not what it ought to; otherwise self-contain the bounded rule. Cite skills by **NAME**, never vendor filesystem path: a path is a GDP-8 designation that can dangle on another host.

> **Known correct exception — reviewer family.** The 22 `*-reviewer` agents have no common narrow > skill; their absence-is-a-claim rule is deliberately inlined. Do not replace it with a dangling > pointer.

| Phase | Load | Trigger | |---|---|---| | Gate or construction design | this core | designing a gate, oracle, error surface, restriction, or a construction alternative | | Context residency | `nw-cross-cutting-context-residency` | choosing resident versus on-demand context, or repairing compensation prose | | Evidence and instrumentation | `nw-cross-cutting-evidence-instrumentation` | asserting from a measurement, demonstrating a check, or repairing a misleading instrument/count | | Input and data contracts | `nw-cross-cutting-input-data-contracts` | adding data, declaring inputs, choosing a join key, or diagnosing ambient reads | | Test time and test location | this core (`test:feedback-loop-budget`) | declaring test budgets, requesting a feature derogation, writing or reviewing a test, placing an infrastructure test, or a default CI suite over its ceiling | | Design simplicity | this core (`design:simplest-design-that-delivers`) | making or reviewing a design decision, receiving a new requirement or owner answer |

The lenses are independent KNOWLEDGE: no forced sequence and no artificial precedence. A compound task loads multiple lenses; return here only to route the next concern.

`delivery:trustworthy-baseline-and-repair-scope` — preserve the safety net without expanding the request

Before product changes, is the required verification trustworthy for the current source and relevant environment? Establish a baseline or reuse applicable evidence; check known local/CI differences early. Follow the project's required checks, not a new full-suite run per slice. Pause affected product changes when that safety basis is broken; independent work needs its own unaffected basis.

Does a failure demonstrate the agreed missing behavior? Expected ATDD RED, including an existing reproduction of the requested bug, permits implementation when execution reaches the intended behavioral assertion and the other required checks remain trustworthy. Collection, setup and incidental failures are not that RED. The expected failure must become GREEN before completion.

Before buying a repair turn, does the intervention satisfy an agreed outcome, restore a regression caused by this request's work, or restore its required safety net? State that connection, observed failure, intervention limit and expected proof in the existing dispatch. Proportionate reversible setup, capture helpers and diagnostic execution already implied by the request need no repeated approval. Missing evidence alone does not establish a product defect. A defect's age alone never decides scope.

If pertinence or cause is unknown, choose the smallest useful discriminator before repairing. Another attempt needs new evidence, a changed falsifiable hypothesis, or a materially different experiment that can obtain the named missing fact; name which outcome would change the next decision. Otherwise retain the affected blocker and uncertainty instead of repeating an inconclusive attempt.

Keep responsibility for regressions caused by preparation and previous repairs too; prefer the smallest restoration, preserving others' work. A newly discovered defect does not inherit repair authority merely from its discovery. Independent redesign, broad migration or new behavior outside the request requires an explicit scope/priority decision with concrete evidence. Reuse existing authorization for routine delivery work. Do not silently absorb unrelated improvements or claim a blocked delivery complete.

Is the required check itself wrong? Its owner may correct the harness or assertion while preserving the agreed property and counterexample. Skipping a required check, weakening its property, or relabeling its failure as optional is not restoration. Report independent defects without silently fixing or dismissing them. Review notes are not automatic same-slice work. The LLM chooses the action; this clause adds no controller, runtime gate, mandatory artifact or guarantee of termination.

`flow:findings-go-to-the-owner-directly` — remove the host relay, not artifact ownership

Is a finding going to the artifact owner, or through a host that only forwards it? For roles on the same Request, send it directly to the owner: crafter ↔ acceptance designer for oracle mismatches; crafter or acceptance designer → architect for a design question or ruling; reviewer → artifact owner for completed findings; any role → product owner for a product question. Include the location (`file:line` or fact id), the relevant authority fact and observation, or the missing/ambiguous authority and precise question.

Does direct contact change who may edit? Keep authorship with the owner: the crafter never edits tests, the acceptance designer never edits production code, only the architect changes design facts, and reviewers never repair. Send completed review