Introduction

The STRATA implementation templates give you the exact documents that practitioners use to govern real features from idea to shipped code. Each template covers the complete decision surface for a feature: what it affects structurally, how data flows, what the security model requires, how tests should be organized, and how work phases should be sequenced.

Templates work because they force systematic thinking before code is written. A practitioner who completes the structural analysis before opening a code editor will have already resolved the questions that typically surface as bugs, missed requirements, or integration failures mid-sprint.

The Three-Phase Process

Every STRATA-governed feature follows the same three-phase sequence, regardless of stack:

Phase 1 — Analysis. Before a line of code is written, you complete the analysis template. This covers the structural footprint — which files, routes, API endpoints, database tables, and components are affected — along with the data model, API contract, security considerations, and a rough test specification. The analysis is not a design document; it is an impact inventory. Its job is to surface everything the feature touches before the cost of touching it becomes real.

Phase 2 — Implementation Plan. The analysis feeds directly into the implementation plan. This document converts the structural inventory into a phased delivery sequence: what is built in which order, what the acceptance criteria are for each phase, and what validation steps confirm each phase is complete. The plan is the agreement between the developer and the governance record.

Phase 3 — Execution. The implementation plan drives execution. Each phase gate is a checkpoint where the criteria from the plan are verified. Deviations are noted explicitly. The execution loop produces the running commit log and phase manifests that form the artifact trail.

The Developer Guide templates cover Phase 1 (analysis) and Phase 2 (implementation plan) for each supported stack. Phase 3 execution artifacts are the developer's own output — the templates establish the standard those artifacts must meet.

Choosing Your Template

Three template sets are available, each specific to a technology stack:

Nuxt / Docus Full-Stack — for SSR documentation portals and full-stack Nuxt applications. Use this template when your project uses Nuxt 4 (often via Docus), Nuxt Content, server-side rendering, and Nitro server middleware. StrataProtocol.org itself is the canonical reference implementation.

NestJS Backend — for API-first, module-based backend services. Use this template when your project is a NestJS application with controllers, services, guards, and an ORM (TypeORM or Prisma) connecting to a relational database. Appropriate for microservice components, enterprise APIs, and standalone backends consumed by a separate frontend.

Vue Frontend — for Vue 3 SPAs consuming a REST or GraphQL API. Use this template when your project is a Composition API Vue application using Pinia for state management and Axios or fetch for data access — a separate frontend codebase with no server-side rendering.

How Templates Map to the STRATA Strata

Templates live inside Stratum 4 — Execution Loop, the stratum that governs iterative feature delivery. But they reference all five strata:

• Stratum 1 (Classification) — the template header captures the feature's classification: which system, what tier, and what change category it belongs to.
• Stratum 2 (Derivation) — the Feature Summary section traces the feature to its requirement source (BRD → PRD → Engineering Standards), confirming it is derived, not improvised.
• Stratum 3 (Construction) — the structural analysis sections map directly onto the construction layer: pages, routes, API contracts, components, composables, database entities.
• Stratum 4 (Execution Loop) — the implementation phases section defines the execution sequence, acceptance criteria, and phase gates.
• Stratum 5 (Verification) — the test specification section ensures verification obligations are defined before code is written, not after.

Filling in a STRATA template is not administrative overhead — each section corresponds to a governance obligation that exists whether or not it is documented. The template makes the obligation explicit and verifiable.

Adapting Templates for Different Project Types

Templates are stack-specific, not project-size-specific. A small feature and a large feature use the same template structure — the difference is in the depth of each section, not the presence or absence of sections. A section that does not apply to a given feature should be marked "Not applicable" with a brief rationale, not deleted. Preserved structure tells future reviewers the section was considered and intentionally skipped, not overlooked.

When working on a project that does not exactly match one of the three supported stacks, choose the closest match and note the deviations in the Template Header. The governance value comes from the structure, not from perfect stack alignment.