enterprise-build

name	enterprise-build
description	Use when a locked enterprise contract exists and implementation must proceed through strict TDD, contract traceability, and staged review handoffs

Enterprise Build

Contract-driven implementation for portable enterprise work.

Required Background

• test-driven-development
• subagent-driven-development when the plan has safe isolated tasks

Entry Gate

Before editing source files, confirm:

• the current agent session recorded the plan
• the current agent session recorded the contract
• the recorded contract status is LOCKED

If any of those are missing, stop and go back upstream.

Required Workflow

1. Read the locked contract, the implementation plan, and the current repo profile.
2. Run the agent-bound build gate in agent-stage-gates.md before editing source files.
3. Implement one postcondition at a time with TDD.
4. Record progress in the build status model from build-status-tracking.md.
5. Record build-stage handoff data in the current agent session before review.
6. Do not add scope that is not in the contract.
7. Run or stage the repo gate commands named by the contract as soon as their prerequisites exist, not only after PR creation.
8. Hand off to enterprise-review after each meaningful task boundary or after the whole build, depending on the path size.

For schema/query/data-sensitive work, the first relevant RED test must be live DB or real integration proof against migrated Postgres. Mocked DB tests may supplement behavior coverage but do not satisfy schema/query proof.

For UI, PDF upload, file upload, preview/download, modal, navigation, or rendered-output work, build must leave a headless browser command ready for review/verify.

For repos with no-new-mock or DB ownership gates, build must keep the diff compliant while coding. Do not introduce new inline DB mocks for schema/query proof, and do not route writes through mixed-owner direct-write files unless the locked contract explicitly owns that seam.

If the locked contract already exists and the prompt asks for the next step, classify the transition as STAGE_ONLY build entry rather than re-triaging the whole program.

If the prompt explicitly states that the committed repo profile and repo-local overlay are already current, do not reopen discover work by default.

Rules

• One RED -> one GREEN
• The test must fail for the right reason before code is added
• Contract amendments only happen through the forge recycle loop
• If a planned task is independent, isolated-task execution is preferred over one large mixed diff
• For bounded work, keep build-status notes terse and leave enough runway for review and verification in the same session
• CI-driven code pivots invalidate previous review/forge coverage for the affected files. Re-run review/forge on the current diff after the pivot.
• Avoid brittle assertions on volatile implementation constants. Idempotence, ranking, tuning, heuristic, or generated-score tests should prove invariant behavior, state transitions, and no-ratchet stability unless the exact number is a locked business rule.