| name | enterprise-harness |
| description | Use when enterprise work has been built and reviewed and needs a final mechanical ship or release gate before merge, PR readiness, install, deploy, or signoff. Checks proof trace, current diff, architecture, post-merge test kit, rollback, observability, security/privacy, and performance regression readiness. |
Enterprise Harness
Final quality gate for enterprise work.
Treat the harness as a fail-closed evidence gate. Schema, query, and data-sensitive changes need live/integration DB proof; UI/PDF/file changes need headless browser proof; every changed runtime file needs code execution proof, E2E trace proof, or a documented non-runtime reason. Full proof is the only pass: PARTIALLY PROVED, UNPROVED, mock-only proof, stale proof, wrong-head proof, missing intent continuity, missing touched-file SRP proof, missing DB/query ownership proof, or missing important edge-case proof fails harness. For async/order/invoice/inventory/pricing/label-printing workflows, missing exact field-spelling, preserved confirmation, commit-boundary, helper return-variant, retry, or rehydration proof is a blocking edge-case gap.
Harness also acts as the senior release-readiness gate. Before ship-ready,
PR-ready, merge-ready, install-ready, or release-level signoff, it must classify
release risk and require the matching operational proof: post-merge validation,
rollback readiness, observability, security/privacy, and performance regression
coverage where relevant. These release gates must be expressed as structured
verification records named enterprise_release_risk,
enterprise_post_merge_test_kit, enterprise_rollback_readiness,
enterprise_observability_proof, enterprise_security_privacy_proof, and
enterprise_performance_regression; validate_release_readiness.py is the
mechanical authority for that proof.
When To Use
- before merge
- before installation of generated skills
- before calling a change ship-ready
Required Behavior
Run the checks in final-gate-checks.md as a fresh pass over the resulting artifacts, not as a recap of what build or review already said.
Before harness starts, run the agent-bound harness gate in agent-stage-gates.md.
For merge or PR readiness, also run the stable enterprise wrapper; do not use raw repo-local gate scripts as the command surface:
enterprise-required-gates --repo-root "$PWD" --stage pr-readiness --agent-id <agent-id> --json
This gate fails if enterprise-review, enterprise-forge, and enterprise-verify were not recorded in order against the current code state or if the receipt-backed proof bundle is incomplete.
Harness also fails if the recorded build_packet is missing, incomplete, or no
longer covers the final changed paths. Mechanical build proof is part of ship
readiness: allowed-path coverage, RED/GREEN receipts, forbidden-change scan, and
refusal-condition status must all be present in review or verification evidence.
The packet must also cover intent-continuity rows, touched-file SRP/refactor
classifications, and DB/query ownership packets for reads, writes, reports,
migrations, verifiers, and live-proof queries.
The same packet must pass validate_architecture_contract.py: module boundary,
folder placement, public seam, owner layer, dependency direction, forbidden
imports, and architecture tests must be exact and evidenced before ship-ready,
PR-ready, merge-ready, or install-ready claims.
Senior Release Gates
Harness must fail closed unless these gates are satisfied or explicitly marked
not-applicable with evidence:
release-risk-classification: classify the lane as low, medium, high,
or critical from the changed surfaces, affected data, blast radius, tenant,
money/order/invoice/inventory/security exposure, migration/config/deploy
impact, and rollback difficulty. Risk decides required proof depth.
post-merge-test-kit-required: for deployable PRs, require a drafted
post-merge-test-kit artifact before merge/pr-readiness, or a recorded reason
that the change is non-deployable. High/critical deployable PRs must include
owner, environment, deployed-SHA proof plan, and agent-run or human-run mode.
rollback-readiness-gate: require rollback owner, rollback trigger,
rollback command/procedure, feature-flag or disable path when applicable,
migration/data rollback posture, and customer/operator communication owner for
high/critical releases.
observability-proof-gate: require exact logs, metrics, dashboards, health
checks, queue/job/readback checks, alert signals, and watch window that will
prove the release is healthy after deploy. "Monitor logs" is not enough.
security-privacy-proof-gate: when auth, tenant scope, permissions, PII,
secrets, payment, webhook, file upload, or external integration boundaries are
touched, require explicit proof and redacted evidence. Secret-bearing evidence
fails the harness.
performance-regression-gate: when hot paths, queries, workers, syncs,
rendering, PDF/file flows, or high-volume loops are touched, require a
regression budget and proof for latency, query plan/index safety, queue
backlog, timeout/retry behavior, or a documented not-applicable reason.
intent-continuity-gate: require proof that the final diff still satisfies the
original user words, business outcome, operator acceptance, and non-goals from
the intake/design. Generic suite PASS is not enough.
touched-file-srp-gate: require proof that each changed file's SRP assessment
was honored, including contracted fix-now refactors for mixed-responsibility
touched files.
db-query-ownership-gate: require owner-seam, current DB/schema, scoping,
affected-row/readback, bounded proof, cleanup, and redaction evidence for every
DB/query path, including read-only SELECT/report/verifier/live-proof queries.
last-150-trap-closure-gate: for PR-producing or branch-window retrospective
work, require structured evidence that every applicable recent trap-bank row is
closed by a current-head ratchet, proof command, gate, or explicit source-backed
non-goal. Stale UI/read-model rehydration, config/env/outage semantics,
proof-lane selector false greens, stale proof-subject/preflight failures, weak
assertions, DB/query ownership gaps, integration side-effect/idempotency faults,
redaction/diagnostic leaks, and SRP/domain-boundary drift cannot be waived by a
broad test-pass summary.
Before a PASS verdict, run:
python3 ~/.codex/skills/enterprise-harness/scripts/validate_release_readiness.py --evidence <verification-artifact> --json
Missing records, vague not-applicable reasons, secret-bearing evidence, and any partial-proof verdict are
blocking failures.
Output
Produce a compact PASS or FAIL verdict with exact failing checks and the blocking reason. Use FAIL for every missing gating record, partial proof, stale proof, unsafe DB target, missing intent-continuity proof, missing touched-file SRP proof, missing DB/query ownership proof, or unproven release-readiness cell; do not downgrade gate gaps to WARN.
For enterprise skill updates based on PR retrospectives, include a baseline-vs-updated behavioral proof summary from old-skill and updated-skill runs. Static file coverage, keyword checks, and deterministic assertion coverage are supporting evidence only; they cannot justify a PASS or done claim for "the skill would have caught the issue" unless model-run behavioral testing is blocked, the blocker is recorded, and the verdict is kept no stronger than BLOCKED/PARTIAL. List each eval prompt, old verdict, new verdict, assertion delta, and remaining unproven trap classes.