Harness Setup

[BLOCKING] Execute skill steps in declared order. NEVER skip, reorder, or merge steps without explicit user approval. [BLOCKING] Before each step or sub-skill call, update task tracking: set in_progress when step starts, set completed when step ends. [BLOCKING] Every completed/skipped step MUST include brief evidence or explicit skip reason. [BLOCKING] If Task tools are unavailable, create and maintain an equivalent step-by-step plan tracker with the same status transitions.

Quick Summary

Goal: Wire every feedforward guide and feedback sensor into the greenfield project so all later AI coding agents operate with maximum guidance and self-correct against quality gates BEFORE human review — raising first-attempt quality and catching defects at the earliest, cheapest stage.

Summary:

• Testability contract: resolve Unit/Integration/System/E2E applicability from runner/config evidence; record owner/root/data, copy-ready full + focused commands, zero-match behavior, CI/simple-Windows entry, unique run/data identity, and repeat proof; unresolved applicable fields block handoff, while non-applicable tiers require evidence-backed N/A.

• BLOCK on the /linter-setup prerequisite first — computational sensors (linters, hooks, CI gates) MUST exist before any phase runs; this skill never installs them itself.

• Walk phases A→F as a hard barrier sequence: detect stack → author feedforward guides (CLAUDE.md conventions, anti-patterns, pattern catalog) → confirm computational sensors → wire inferential review skills to lifecycle gates → define behaviour/test strategy → emit inventory.

• Treat every feedforward-guide and sensor choice as AskUserQuestion-gated — never auto-decide content — why: harness conventions bind every future agent and silent choices propagate.

• Write .ai/workspace/harness/harness-inventory.md incrementally (append per phase, never held in memory) — keep it a LIVING document updated as new sensors are added.

Main steps (run in order — each BLOCKS the next):

1. Guards — BLOCK until /linter-setup verified (linter config + pre-commit hook + CI gate present); detect existing inventory (enhance, never skip).
2. Phase A — Stack Detection — read plan / architecture-design / tech-stack reports; write stack-profile.md; AskUserQuestion on any undetectable field.
3. Phase B — Feedforward Guides — author/enhance CLAUDE.md/AGENTS.md (architecture patterns, anti-patterns, naming, module boundaries) + skill-activation rules + docs/architecture/* notes + pattern catalog; confirm via AskUserQuestion.
4. Phase C — Computational Sensors — confirm /linter-setup outputs; list config paths (invoke /linter-setup if any missing).
5. Phase D — Inferential Sensors — wire review skills to lifecycle gates (/why-review pre-impl · /code-review pre-commit · /domain-entities-review post-impl · /production-readiness-review + /security-review pre-release · /scan-codebase-health recurring · /integration-test-review feature-area TC audit BOTH pre-release AND recurring — closes the diff-scoped blind spot); record under "## Review Gates".
6. Phase E — Behaviour Harness — pick spec format, define test pyramid + approved fixtures, gate on mutation score (NEVER line %), add property/behavior coverage; write test-strategy.md.
7. Phase F — Inventory Report — append harness-inventory.md (feedforward + computational/inferential sensors + open gaps); present via AskUserQuestion.
8. Next Steps — AskUserQuestion: /feature-implement (recommended) · /why-review · skip.

Produces:

• Feedforward guides: CLAUDE.md/AGENTS.md conventions, architecture docs, pattern catalogs, skill activation rules
• Computational feedback sensors: configured via /linter-setup (linters, formatters, pre-commit hooks, CI gates)
• Inferential feedback sensors: AI review skills wired to lifecycle stages
• Harness inventory: .ai/workspace/harness/harness-inventory.md

When invoked: After /scaffold + /linter-setup in greenfield workflow. Assumes scaffolding complete.

Does NOT do: Install linters or configure formatters — that is /linter-setup's responsibility.

Activation Guards

Check 1 — Linter-setup prerequisite (BLOCK if missing): Before running any phases, verify /linter-setup completed by checking for:

• Linter config file at project root (e.g., .eslintrc, pyproject.toml, .editorconfig)
• Pre-commit hook config (e.g., .husky/, .pre-commit-config.yaml)
• CI quality gate definition

If any missing → AskUserQuestion: "/linter-setup appears incomplete. Computational feedback sensors must be in place before harness setup. Run /linter-setup first, then return here?" BLOCK Phase A/B/C/D/E until linter-setup verification passes.

Check 2 — Existing harness inventory: Check for .ai/workspace/harness/harness-inventory.md

• If found → AskUserQuestion: "Harness inventory already exists — re-run to enhance existing harness, or skip?"
• Proceed even when CLAUDE.md/AGENTS.md present — those are feedforward guides this skill may enhance, NEVER signals to skip

Phase A — Stack Detection

Read from: plan.md frontmatter → architecture-design report → tech-stack-comparison report.

Extract:

• Primary language(s) and framework(s)
• Test framework and test runner
• CI provider/tooling
• Package manager and monorepo structure (if any)
• Module system and build tooling

Write detection result to .ai/workspace/harness/stack-profile.md.

If any field undetectable → AskUserQuestion to confirm before proceeding.

Phase B — Feedforward Guide Setup (Inferential)

For each guide type, check if it exists; if not, create or enhance:

1. CLAUDE.md / AGENTS.md — Architecture conventions

• Add section: "Architecture Patterns" — document the patterns chosen in /architecture-design (e.g., Clean Architecture, CQRS, Repository)
• Add section: "Anti-Patterns" — explicit list of patterns to avoid for this stack
• Add section: "Naming Conventions" — language-idiomatic conventions for this repository
• Add section: "Module Boundaries" — which layers may import which; dependency direction rules

2. Skill activation rules

• Document in CLAUDE.md which skills auto-activate for common task types in this stack
• Example: "When modifying domain entities → activate /domain-entities-review"
• Example: "Before any commit → run /code-review"

3. Architecture notes

• Create docs/architecture/ with:
  • bounded-contexts.md — domain boundaries and ownership
  • dependency-rules.md — allowed import directions between layers
  • naming-conventions.md — project-specific naming for files, classes, functions

4. Pattern catalog

• Create docs/architecture/pattern-catalog.md
• Document each pattern chosen in /architecture-design with DO/DON'T examples
• Anchor to actual project files once scaffolding produces them

Present list of guides created/updated via AskUserQuestion: "Feedforward guides above will be created/enhanced. Confirm or adjust?"

Phase C — Computational Feedback Sensors

Confirm /linter-setup has completed:

• Check for linter config file at project root (e.g., .eslintrc, pyproject.toml, .editorconfig)
• Check for pre-commit hook config (e.g., .husky/, .pre-commit-config.yaml)
• Check for CI quality gate definition

If any missing → invoke /linter-setup before continuing.

Output: confirmation that computational sensors are in place, with file paths listed.

Phase D — Inferential Feedback Sensors

Configure which AI review skills fire at each lifecycle stage. Present to user via AskUserQuestion: "Which inferential sensors should be mandatory vs optional for this repository?"

Pre-implementation (planning gate):

• /why-review — validate design rationale before committing to implementation approach

Pre-commit (lightweight review):

• Document in CLAUDE.md: run /code-review before committing significant changes

Post-implementation (domain model changes):

• /domain-entities-review — when domain entity files are in the changeset

Pre-release (mandatory gates):

• /production-readiness-review — reliability and operational readiness
• /security-review — security review before production release

Recurring drift detection:

• /scan-codebase-health — schedule quarterly (or on CI schedule) to detect drift
• /integration-test-review — Missing Integration Test / Spec-Coverage Gate: feature-area-wide TC audit (Phase 3 addendum in that skill) catches orphaned Section-8 TCs and uncovered changed behavior. Wire BOTH pre-release (mandatory gate, alongside /production-readiness-review and /security-review) AND same recurring cadence as /scan-codebase-health — a diff-scoped run alone cannot see a TC whose covering test regressed outside the current change set; only a periodic feature-area sweep does.

Add the agreed sensor configuration to CLAUDE.md under "## Review Gates".

Phase E — Behaviour Harness (Spec + Test Strategy)

Define the project's behaviour harness plan:

Functional spec format:

• AskUserQuestion: "Feature documentation format?" Options: feature-spec (8-section tech-free), TDD specs only, lightweight ADRs
• Establish docs/specs/ or equivalent spec home

Test strategy pyramid:

• Unit: pure functions, domain entities, business logic (no I/O)
• Integration: subcutaneous CQRS tests, repository tests with real DB
• E2E: critical user journeys only (not full coverage — too slow)

Approved fixtures pattern:

• Pre-seed reference/lookup data as approved snapshots
• Integration tests are additive (never delete/reset data)

Testability & Execution Matrix (write to test-strategy.md)

Copy the architecture-design contract into the strategy and resolve every tier from verified project/configuration evidence before choosing tools:

APPLICABLE requires runner/framework/configuration/root/command evidence. If no E2E framework, configuration, and command are verified, record N/A — {config/source evidence}; do not infer a browser stack from generic examples. Full and focused commands must be copy-ready, report exact counts/exit status, and fail invalid or zero-match selection.

Run, Data, Isolation & Repeat Policy (write beside the matrix)

For each applicable persistent-state tier, record the run/test identity generator and unique business-data suffix, supported public-path arrangement, realistic valid data, count-before-create idempotent/restart-safe reference setup, additive keyed accumulation with integrity checks, mutable-root and parallel-worker isolation, immutable data that may be shared, realistic actor pacing and observable arrange barriers, and the exact result. Require two consecutive no-reset full runs; until executed, mark the proof planned — {owner} rather than PASS. Keep property/invariant, mutation, change, and behavior coverage meaningful; line coverage remains diagnostic only.

Test-strength sensors (NOT a line-coverage gate):

• Line coverage is a diagnostic only — NEVER gate a build on it. Low coverage is a useful NEGATIVE signal (an area is untested → investigate); high coverage is NOT evidence of quality (lines can execute with no meaningful assertion). Report it as a diagnostic; do not fail CI on a coverage %.
• Mutation score is the real test-strength metric — gate on this. AskUserQuestion: "Configure a mutation-testing tool (e.g. Stryker / PITest / mutmut, per stack) as the CI test-quality gate?" A surviving mutant = a fault your tests did not catch = a missing/weak assertion. Add a minimum mutation-score threshold to CI as the computational test-strength sensor.
• Property coverage (optional second sensor): each named business invariant guarded by ≥1 property/metamorphic test. Track which invariants have a property test; an unguarded invariant is a gap to fill.
• Keep behavior/change-coverage (meaningful, not a %): every behavior-changing file must have a test that asserts the changed outcome — see /integration-test-review Gate 7. This is the right notion of "coverage"; the line-% is not.

Document agreed test strategy to docs/architecture/test-strategy.md.

Phase F — Harness Inventory Report

Write .ai/workspace/harness/harness-inventory.md:

# Harness Inventory

Generated: {date}
Stack: {detected stack from Phase A}

## Testability & Verification Contract

Copy the resolved `test-strategy.md` matrix into this inventory and keep the status current:

**Status:** `PASS | PARTIAL | BLOCKED`

| Tier | Applicability + evidence | Owner | Runner/config/root | Full | Focused/partial | Zero-match behavior | CI / simple-Windows entry point | Identity/data/isolation/fidelity policy | Repeat proof |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| Unit | `APPLICABLE` / `N/A — {evidence}` | {owner} | {runner/config/root} | `{command}` | `{filter}` | `{non-zero behavior}` | {gate / command} | {policy reference} | {result/status} |
| Integration/System | `APPLICABLE` / `N/A — {evidence}` | {owner} | {runner/config/root} | `{command}` | `{filter}` | `{non-zero behavior}` | {gate / command} | {policy reference} | `{two no-reset runs}` |
| E2E | `APPLICABLE` / `N/A — {evidence}` | {owner} | {runner/config/root} | `{command}` | `{filter}` | `{non-zero behavior}` | {gate / command} | {policy reference} | `{result or evidence-backed N/A}` |

Missing/placeholder evidence is an open gap, not a PASS. The inventory must preserve the strategy's unique identity, additive-data, isolation, realistic-fidelity, and two-run proof fields; E2E N/A remains evidence-backed.

## Feedforward Guides

| Type          | File/Skill                           | Purpose                         |
| ------------- | ------------------------------------ | ------------------------------- |
| Inferential   | CLAUDE.md §Architecture Patterns     | Shapes AI architectural choices |
| Inferential   | CLAUDE.md §Anti-Patterns             | Prevents known bad patterns     |
| Inferential   | docs/architecture/pattern-catalog.md | DO/DON'T examples per pattern   |
| Computational | .editorconfig                        | Cross-IDE consistency           |

## Feedback Sensors — Computational

| Stage      | Tool/Hook          | What it catches                                |
| ---------- | ------------------ | ---------------------------------------------- |
| Pre-commit | {linter}           | Style violations, common errors                |
| Pre-commit | {formatter}        | Code formatting drift                          |
| CI         | {type-checker}     | Type errors                                    |
| CI         | {static-analyzer}  | Security, complexity, dead code                |
| CI         | {mutation-tool}    | Weak/missing assertions (test-strength GATE)   |
| CI         | {coverage-tool}    | Untested areas (DIAGNOSTIC only — never gated) |

## Feedback Sensors — Inferential

| Stage               | Skill/Agent             | What it catches                |
| ------------------- | ----------------------- | ------------------------------ |
| Pre-implementation  | /why-review             | Design rationale gaps          |
| Pre-commit          | /code-review            | Convention drift, logic errors |
| Post-implementation | /domain-entities-review | Domain model quality           |
| Pre-release         | /production-readiness-review             | Operational readiness          |
| Pre-release         | /security-review               | Security vulnerabilities       |
| Pre-release + Recurring | /integration-test-review (feature-area TC audit) | Orphaned Section-8 TCs, uncovered changed behavior |

## Open Gaps

| Area                     | Reason   | Risk           |
| ------------------------ | -------- | -------------- |
| {area not yet harnessed} | {reason} | {LOW/MED/HIGH} |

Present inventory to user for review via AskUserQuestion.

Next Steps

AskUserQuestion:

• "/feature-implement (Recommended)" — Begin implementing the project plan with full harness in place
• "/why-review" — Review harness design rationale before proceeding
• "Skip" — Proceed manually without workflow guidance

[IMPORTANT] Use TaskCreate to break ALL work into small tasks BEFORE starting — including tasks for each file read. This prevents context loss from long files. For simple tasks, AI MUST ATTENTION ask user whether to skip.

Critical Thinking Mindset — Apply critical thinking, sequential thinking. Every claim needs traced proof, confidence >80% to act. Anti-hallucination: Never present guess as fact — cite sources for every claim, admit uncertainty freely, self-check output for errors, cross-reference independently, stay skeptical of own confidence — certainty without evidence root of all hallucination.

AI Mistake Prevention — Failure modes to avoid on every task:

Re-read files after context changes. Context compaction, resume, or long-running work can make memory stale; verify current files before acting. Verify generated content against source evidence. AI hallucinates APIs, names, claims, and document facts. Check the relevant source before documenting or referencing. Check downstream references before deleting or renaming. Removing an artifact can stale docs, generated mirrors, configs, and callers; map references first. Trace the full impact chain after edits. Changing a definition can miss derived outputs and consumers. Follow the affected chain before declaring done. Verify ALL affected outputs, not just the first. One green check is not all green checks; validate every output surface the change can affect. Assume existing values are intentional — ask WHY before changing OR flagging one as a defect. Before changing or reporting a constant, limit, flag, cutoff, wording, or pattern, read nearby context and history, the CALLER's ordering, and 2+ sibling call sites of the same convention. A doc stating WHAT without WHY is missing rationale, not proof of a missing guard. Surface ambiguity before acting — don't pick silently. Multiple valid interpretations require an explicit question or stated assumption with risk. Assert the outcome your system owns, not the intermediate state your infrastructure owns. When verifying async work, assert the final business state — never the delivery/retry bookkeeping held in shared infrastructure that any co-running process can write. Such a check passes when run alone and flakes the moment anything else shares that infrastructure. Keep shared guidance role-relevant. Universal guidance must help every receiving skill or agent; code-specific obligations belong only in code-specific protocols.

Harness Engineering — An outer agent harness has two jobs: raise first-attempt quality + provide self-correction feedback loops before human review.

Controls split:

Axis	Type	Examples	Frequency
Feedforward	Computational	.editorconfig, strict compiler flags, enforced module boundaries	Always-on
Feedforward	Inferential	CLAUDE.md conventions, skill prompts, architecture notes, pattern catalogs	Always-on
Feedback	Computational	Linters, type checks, pre-commit hooks, ArchUnit/arch-fitness tests, mutation-score gate, CI gates	Pre-commit → CI
Feedback	Inferential	/code-review skill, /production-readiness-review, /security-review, LLM-as-judge passes	Post-commit → CI

Test-strength sensor — gate on mutation score, NOT line coverage. Line coverage is a DIAGNOSTIC only: low coverage is a useful NEGATIVE signal (something is untested); high coverage is NOT evidence of quality (tests can execute lines without asserting intent) — NEVER fail a build on a line-coverage %. The real test-strength metric is mutation score (inject faults into changed code; surviving mutant = a missing/weak assertion = write the killing test); gate the build on it where a mutation tool exists. Where no workable tool exists the obligation does NOT lapse — it falls back to the deliberate defect-seeding drill: break the production code behind a top invariant, run the suite, record WHICH NAMED TEST went red, restore. Nothing went red ⇒ that behavior has no protection; write the killing test. The drill needs no tooling, works in every ecosystem, costs one edit-run-revert cycle per behavior, and is what makes test-strength checkable rather than aspirational — full contract in SYNC:engineering-foundation-gate F4. Add property coverage as a second sensor — each [HARD] §4 rule / §5 invariant guarded by ≥1 property/metamorphic test. The property tests themselves are REQUIRED for invariant-owning behaviors (spec [mode=tests] + integration-test force them, not opt-in); what is optional is only wiring property coverage as an automated CI sensor on top. Keep behavior/change-coverage (does each behavior-changing file have a test that asserts the changed outcome) — that notion is meaningful and stays.

Three harness types:

1. Maintainability — Complexity, duplication, line-coverage (diagnostic only — never a gate), style. Easiest: rich deterministic tooling.
2. Architecture fitness — Module boundaries, dependency direction, performance budgets, observability conventions, and build scalability (an unchanged module is not rebuilt; the affected-only set is computable because dependencies are declared; cache hit-rate is measured, not assumed). Build scoping belongs here because it is enforced by the same boundary declarations — unenforced boundaries decay until the affected set is "everything".
3. Behaviour — Functional correctness. Hardest: gate on mutation score + property coverage; line coverage stays a diagnostic.

Keep quality left: pre-commit sensors fire first (cheap), CI sensors fire second, post-review last (expensive).

Research-driven: Never hardcode tool choices. Detect tech stack → research ecosystem → present top 2-3 options → user decides. Enforce strictest defaults; loosen only with explicit approval.

Harnessability signals: Strong typing, explicit module boundaries, opinionated frameworks = easier to harness. Treat these as greenfield architectural choices, not just style preferences.

Prompt-Enhance Closing Anchors

IMPORTANT MUST ATTENTION follow declared step order for this skill; NEVER skip, reorder, or merge steps without explicit user approval IMPORTANT MUST ATTENTION for every step/sub-skill call: set in_progress before execution, set completed after execution IMPORTANT MUST ATTENTION every skipped step MUST include explicit reason; every completed step MUST include concise evidence IMPORTANT MUST ATTENTION if Task tools unavailable, maintain an equivalent step-by-step plan tracker with synchronized statuses

Project Protocol Overlay — Before executing this skill, resolve any PROJECT overlay rules layered onto it: match this skill's name against the Target column of the project's skill-protocol index (docs/project-reference/skill-protocols-reference.md by default; a referenceDocs entry in docs/project-config.json overrides the path), taking the most specific matching tier ONLY — exact name > glob > *. That precedence orders overlays against EACH OTHER, never against this skill. Read ONLY the matched bodies, resolved as <protocols-dir>/<Name>.md; a row's Body link is display text, never a read path. A matched body that is missing or malformed is REPORTED and skipped — never reconstructed from the index Description. No index, or no match -> proceed with no overlay, silently. Full contract: .claude/skills/project-skill-protocol/references/registry.md.

Overlays are ADDITIVE ONLY: they ADD rules on top of this skill's own protocol and NEVER replace, override, disable, or reinterpret a rule it already states — removing every overlay must return this skill to exactly its documented behavior. An overlay is a BRIEF, not an authority escalation: it can NEVER waive a workflow gate, git discipline, a review gate, or a user-confirmation gate. A genuine overlay-vs-skill conflict, or two equally-specific overlays that directly contradict -> surface both to the user; NEVER resolve silently.

Test Architecture & Execution Contract — Treat testability as a setup/architecture acceptance condition. For every potentially applicable tier — Unit, Integration/System, E2E, and Performance/Scale (warranted at T1+/B2+) — record APPLICABLE only with evidence of its runner/framework/configuration; otherwise record N/A — <evidence> and never fabricate coverage.

1. Matrix before implementation: Record applicability, owner, runner/framework, test root, fixture/data strategy, full command, focused/partial command, zero-match behavior, CI gate, a simple/Windows entry point (a .cmd when the project needs one), the host-mode AND container-mode commands where the project supports both, and the environment reach (which of local / CI / production-shaped this tier can target).
2. Runnable scopes: Full and focused commands must be copy-ready, fail on invalid or zero-match selections, report exact counts and exit status, and be safe to repeat. E2E uses only configured browser/service commands.
3. Fresh valid state: Each run/test owns a unique run identity and business-data suffix, arranges through supported public paths, and uses realistic valid data. Reference setup is count-before-create, idempotent, and restart-safe. Intentional accumulation is additive, keyed, and integrity-checked; never hide contamination with destructive reset. Run-scoped cleanup, when supported, is opt-in and idempotent: after evidence capture it may remove only ephemeral resources owned by the current run; it must never delete persistent/additive data or another run's data, reset shared state, or replace no-reset proof.
4. Isolation and fidelity: Isolate mutable roots and parallel workers; share only immutable/reference data. Preserve real actor pacing and observable arrange barriers. Do not widen retries or weaken assertions to make a scenario pass.
5. Evidence gate: Report command, scope, identity, seed/accumulation mode, exact result, and repeat proof. For each applicable persistent-state suite, require two consecutive no-reset full runs. Treat line coverage as diagnostic only; use meaningful property/invariant, mutation, change, and behavior coverage signals.
6. Execution modes and environment reach: A tier claiming two run modes must have BOTH exercised — the bare-host command and the fully-containerized command, driven from ONE source of truth for config and topology; record which mode CI exercises, because an unexercised mode rots silently and a claimed-but-rotten mode is worse than one never claimed. The SAME suite must reach local, CI and (where warranted) a production-shaped target, parameterized by configuration, never by forked test code — only one fork ever stays maintained, so forking guarantees divergence. A target lacking a required capability reports ENVIRONMENT-BLOCKED, never a silent pass. Tests unsafe against production are excluded by an ENFORCED mechanism whose absence fails loudly, not by a convention someone must remember; "runs in prod" means a safe, declared, NON-MUTATING subset. Reproducibility underwrites all of it — pinned toolchain, locked dependencies, declared external prerequisites — which is the difference between a suite that passes anywhere and one that passes on its author's machine. Depth → SYNC:engineering-foundation-gate F1/F2/F3.

Ownership: Architecture/harness defines the matrix; scaffold/workflow makes it runnable; test writers implement tier-specific cases; reviewers verify the contract; the runner reports; seed-data owners preserve uniqueness, idempotency, realism, and accumulation integrity. Missing required evidence blocks setup completion.

Engineering Foundation Gate — CONDITIONAL, evidence-gated, profile-tiered. Judges the PROJECT'S ENGINEERING FOUNDATION: can this team build, run, test and change the system safely — anywhere, repeatably, as it grows? Its companions judge the running system's DESIGN (scale-technique-gate: is technique X present? · scenario-stress-eval: does it survive scenario Y?) — a system can score perfectly on both while nobody but its author can build it. State OUTCOMES, never tools: detect the stack, research the current ecosystem, present 2–3 options, the user decides, record the decision — best practice turns over, the outcome does not.

1. Derive the project profile FIRST — from evidence, never assumed. Lifecycle G greenfield (foundation being created) / B brownfield (foundation exists, under audit) · scale T0–T3 (reuse scale-technique-catalog.md, never re-derive) · criticality B0–B3 with its criticality-signal floor (reuse scenario-stress-catalog.md) · repo shape R0 single module / R1 few (2–5) / R2 many modules, multi-team / R3 monorepo estate · runtime surface. Cite file:line/config/CI + confidence. Unknown axis → state the assumption and take the LOWER tier; NEVER default to T3/B3/R3 — an over-stated profile turns this gate into busywork a small team correctly ignores.
2. Judge all 7 dimensions — always all 7, never a filtered subset (an omitted row is indistinguishable from an overlooked one). Depth belongs to the named owner; this gate decides only present/absent:
   • F1 Reproducible environment (ALL profiles — the floor) — one documented path takes a clean machine to a running system; toolchain versions pinned; dependencies locked to exact versions; every external prerequisite declared with a way to obtain or fake it; config environment-injected, never machine-implicit; build deterministic. This is what kills "works on my machine" — not carelessness, but a build depending on ambient state nobody declared. → scaffold · architecture-scalability-review
   • F2 Dual execution modes (T1+, multi-contributor, or containerized target; B2+ regardless of scale) — the system runs on the bare host AND fully containerized from ONE source of truth for config and topology, and the suites run in BOTH directions (host-run against a containerized system, and wholly inside a container). Both modes exercised, so neither rots. Host mode buys a fast inner loop and a debugger; container mode buys CI/production parity and a trustworthy day one — a project with only one teaches people to work around it undocumented. A mode honestly dropped with a stated reason is N/A; the defect is the claimed-but-rotten mode. → scaffold · devops · production-readiness-review
   • F3 Environment-portable tests (local+CI all profiles; production-shaped T1+/B2+) — the SAME suites run against local, CI and production-like targets, parameterized by configuration, never by forked test code (only one fork ever stays maintained, so forking guarantees divergence). Missing capability reports ENVIRONMENT-BLOCKED rather than silently passing; unsafe-in-production tests are excluded by an enforced mechanism whose absence fails loudly, not by a convention someone must remember. "Runs in prod" means a safe, declared, NON-MUTATING subset. → test-architecture-execution-contract · integration-test-review
   • F4 Test-strength proof (wherever tests exist) — evidence the suite actually fails when the code is wrong; a passing suite means nothing until it is known to be capable of failing for the right reason. Strongest available first: (a) automated fault injection scoped to CHANGED code — a surviving defect is a missing or vacuous assertion; gate on it where the ecosystem offers a workable tool. (b) Deliberate defect-seeding drill — the universal fallback, needing no tooling and available in every ecosystem: break the production code behind a top invariant, run the suite, record WHICH NAMED TEST went red, restore. Nothing went red ⇒ that behavior has no protection — write the killing test. (c) Assertion-intent audit: flag assertions that would still hold under an inverted implementation, that assert only non-nullness or a type, that re-assert the input, or that assert infrastructure bookkeeping instead of the outcome the system owns. Line coverage is a DIAGNOSTIC, never a gate — low coverage is a useful negative signal; high coverage is not evidence of quality, and gating on the percentage reliably produces tests written to touch lines rather than protect behavior. Scope boundary — do NOT re-litigate a solved question: this gate asks only whether the PROJECT HAS a test-strength mechanism wired into its harness at all; PER-CHANGE enforcement is already owned by integration-test-review Gate 1's Mutation Probe Ledger (tool path + manual fallback, ledger required either way). Report the setup gap here, the assertion gap there, never both. → harness-setup (sensor design) · integration-test-review (per-change enforcement)
   • F5 Performance & scale-under-data (T1+/B2+ for a real tier; T0/B0 = one documented largest-expected-volume check) — performance MEASURED by something that RUNS and CAN FAIL, not reasoned about. The companion gates can be fully satisfied by a system that has never once been run against a large dataset; this is the executable counterpart. Requires: a runnable perf tier with a documented command (it belongs in the tier matrix); on-demand realistic volume AND realistic shape — distribution, cardinality, skew, not a million identical rows; named latency/throughput/memory budgets the run ASSERTS (a perf test that only reports numbers is a dashboard, and eventually nobody reads it); growth compared across ≥2 volumes ~10× apart, because one data point cannot distinguish O(n) from O(n²); and resource exhaustion as a tested, bounded outcome — backpressure, paging or a clean error rather than an OOM kill, with unbounded result-sets, unbounded in-memory accumulation and unbounded concurrency provably absent or bounded on the paths that matter. State whether a number is a regression signal or a capacity statement. → performance-review · seed-test-data
   • F6 Build & change scalability (R1+ declared style + boundaries; R2+ computable affected set, enforced checks, measured incrementality) — build/test cost and blast radius do NOT grow with the codebase. Every project is fast on day one; the foundation question is whether the tenth module costs what the second did. Requires: the affected module/sub-domain set is COMPUTABLE because inter-module dependencies are explicit and declared; incrementality and caching are real and measured (claimed caching that never hits is an invisible failure); boundaries enforced MECHANICALLY, since unenforced boundaries decay silently until the affected set is "everything"; a declared architecture style (modular monolith / clean / hexagonal / layered — which one matters far less than that one is declared, written down and enforced, because an undeclared style is indistinguishable from none after two years); implementation hidden behind abstraction so a technology swaps without touching business code (depth → complexity-prevention); and a fast scoped inner-loop check — if the only available check is the slow exhaustive one, that is the finding. Scope boundary: architecture-scalability-review G2 Build & CI Scalability already SCORES incremental/affected-only/caching/monorepo posture and G4 scores boundary enforcement — where that review has run, cite its verdict rather than re-scoring; this gate only confirms the dimension was examined and is not silently absent. → architecture-scalability-review (G2/G4 depth) · architecture-review (diff-level boundary drift) · complexity-prevention (cost of change in the code itself)
   • F7 Mechanical quality harness (format + lint + type/static analysis + build/test at ALL profiles; architecture-fitness R1+; dependency health + secret scanning wherever real data ships, unconditional at B2+; complexity/duplication + drift R1+/T1+) — no human reviewer spends attention on a defect class a machine could have caught; reviewer attention is the scarcest resource in the project. Account for EVERY class or record it N/A with a reason — an unlisted class is an unexamined one: formatting · lint/correctness · type & static analysis · complexity & duplication · executable architecture-fitness · dependency vulnerability & license · secret scanning · build/test gates plus the F4 signal · documentation/config drift. Local and CI must run the SAME command, configuration and version (divergence means CI failures nobody can reproduce); checks must ENFORCE, not warn (an unread warning stream is not a harness); strictest reasonable defaults, loosened only with a recorded reason, since a large silent suppression list is itself a finding; cheap checks first, expensive last. Brownfield adoption uses a ratchet — fail on NEW violations, tolerate the existing baseline — which counts as PRESENT, not partial, because it stops regression from day one. → linter-setup · harness-setup · security-review
3. Assign one verdict per dimension: PRESENT (achieved and proven by cited evidence) · MISSING-WARRANTED · PARTIAL-WITH-PATH (gap named + concrete incremental step) · N/A-by-profile (below the warranting profile — a correctly-lean project is a PASS here, never a gap; never report it as a deficiency) · OVER-ENGINEERED (present but unwarranted → advise AGAINST, name the carrying cost) · UNVERIFIED (could not be checked — say so honestly; NEVER score an unverified dimension PRESENT).
4. **Authority is context-split

…(truncated)