# Engineering standard for [project or portfolio]

**State:** Proposed / Adopted (choose the actual state)
**Scope:** [owned projects/repositories; exclusions; contributed/upstream treatment]

Replace examples with the smallest useful policy. Separate required rules, recommended defaults, and conditional requirements. Omit sections without a real responsibility; documenting a policy does not enable remote settings.

## Coverage and applicability

For a comprehensive standard, cover the domains in `references/standards-coverage.md` of the engineering-standards skill. Combine related domains into existing documents when useful.

| Domain | Baseline / default / conditional / not applicable / gap | Concrete rule or decision | Owner / authority | Verification / adoption step |
|---|---|---|---|---|
| [applicable domain] | [level and reason] | [usable decision] | [known owner or TBD; canonical location] | [meaningful check] |

Do not leave every decision as TBD or describe configured/enforced behavior without evidence.

## Identity and boundaries

- Logical project ID(s) and display name(s):
- Repository keys, ownership, roles and consumers:
- Coordination repository and authoritative project map:
- GitHub Projects, purpose of each, canonical task status and outcome authority:
- Local clones/worktrees and private mapping location:

## Naming and compatibility

| Identifier | Current convention | New-work default | Legacy aliases / exceptions |
|---|---|---|---|
| Project / repositories | [observed] | [stable names and role suffixes] | [preserved identifiers] |
| Files / modules / packages | [ecosystem] | [language-compatible rules] | [public import/module paths] |
| Branches / commits / releases | [observed] | [review and version conventions] | [existing automation] |

## Layout and documentation tiers

- Small app/tool baseline:
- Operated service/platform additions:
- SDK/research/site differences where relevant:
- Existing source and document roots to preserve:
- Product scope, architecture, contract, data, operation and decision authorities:
- Documentation status and update triggers:

## Design and delivery

- When a feature needs a brief/plan and what acceptance evidence it needs:
- Issue ownership, coordinating issues and cross-repository dependencies:
- Board states, blocked/canceled treatment, WIP and priority meaning:
- PR/review policy for the actual maintainer/team model:
- Applicable CI checks and current enforcement gaps:
- Contract/version evolution, integration checks and partial-rollout recovery:
- Release, support/deprecation and deliberate archival:

## Local development, configuration and dependencies

- Supported OS/CPU/toolchain and install/lockfile policy:
- Native / dependency-container / full-container development mode and why:
- Bootstrap, start, verify, test, logs, stop and dependency-refresh commands:
- Compose project/worktree identity, ports, networks, mounts/permissions and health/readiness where used:
- Persistent/test data ownership, seed/migration, backup and explicitly separate reset:
- Environment precedence, secret sources, public/browser settings and required-value validation:
- Dependency/base-image upgrade, package provenance and reproducible build policy:

## Quality, data and collaboration

- Meaningful checks by change risk; no unsupported coverage or deployment claims:
- Data/contract ownership, authorization/tenancy/payment rules when applicable:
- Secret/runtime artifact storage and research data/reproducibility when applicable:
- Agent task boundaries, existing work preservation and handoff evidence:
- API/event errors, limits, versioning, retry/idempotency and consumer compatibility:
- Actual schema/backfill mechanism, migration ordering and recovery:
- Frontend states, keyboard/focus/accessibility and supported clients, when applicable:
- Preferred UI library/source, verified package/version/styles/providers, component/token authority and focused fallback reasons:
- Measurable performance/reliability needs, telemetry and relevant incident/restore procedures:

## Adoption and exceptions

| Step | Concrete outcome | Affected repositories | Validation / compatibility |
|---|---|---|---|
| 1 | [additive first cohort] | [keys] | [checks] |
| 2 | [next useful change] | [keys] | [checks] |

For a real exception, record scope, reason, compatibility impact, decision owner/source if known, and review trigger. Preserve existing conventions until their migration is deliberately included.