engineering-baseline

Engineering Baseline

Use this as a routing and quality baseline, not as a reason to narrate process or apply every checklist to every change.

Work sequence

1. Read .engineering-baseline-lock.json. If adoption.status is pending, or the lock is absent in an existing application, invoke Adopt Existing Project. Perform only read-only discovery, present the assessment/questions, and wait for explicit user approval before any project changes or application commands.
2. Read repository instructions and inspect relevant code before proposing a change.
3. Clarify material ambiguity; otherwise make the smallest safe assumption and state it when it affects the result.
4. Load the relevant specialized skills:
   • Adopt Existing Project for first-run assessment, production migration, restructuring or baseline application to an existing codebase.
   • Ponytail for scope reduction and minimal implementation.
   • Superpowers skills for planning, TDD, debugging, review, and verification.
   • Impeccable for user-interface or product-design work.
   • Security Review for every new feature and material behavior change. Use its lightweight N/A record when no executable behavior or trust boundary changes.
   • Production Full-Stack when creating or changing an app, API, backend, frontend, worker, queue, database-backed feature or deployment.
5. Implement the smallest maintainable change that satisfies the approved request.
6. Test proportionally to the change's risk and run existing relevant checks.
7. Review the diff for unintended scope, regressions, exposed secrets, missing validation, accessibility issues, and incomplete error handling.
8. Report the outcome and concrete verification evidence.

Invariants

• Correctness and security outrank minimalism.
• Existing-project adoption is plan-first: no application changes before the read-only assessment, required questions and explicit user approval.
• Do not remove validation, authorization, error handling, observability, or accessibility merely to reduce lines of code.
• Do not invent tools, subagents, scanners, or test results that are unavailable.
• Do not claim completion without fresh evidence.
• State STRIDE mitigations before implementing a feature and verify applicable ASVS Level 2, OWASP Top 10, NIST CSF, and Zero Trust outcomes afterward.
• For production application work, require Docker/Compose, queue/worker and concurrency design, caching/rate limits, pagination, audit events, consistent APIs/UI, documentation updates, review and production evidence.
• Keep always-on guidance short; use specialized skills for detail.

Read references/precedence.md only when installed skills appear to conflict.