be-framework-coding-standard

BE Framework Coding Standard

When to use

You are BE Dev implementing or reviewing backend code after the backend track and stack are declared in the signed-off SRS. This skill standardizes backend implementation without turning a feature task into a framework migration.

Inputs and outputs

• Inputs: task assignment, docs/SRS.md headers Backend-Track: and Backend-Framework:, SRS §3.4.4 API Contract Format, SRS §3.4.5 Source Layout, SRS §3.4.6 Environment Configuration, task US / FR / NFR IDs, architecture, data-contract constraints, external-integration specs, current backend source tree, manifests, and installed framework versions.
• Outputs: backend code under the declared backend source root, framework-native handlers/controllers/services/repositories/workers, API contracts when endpoints/messages change, validation/error/observability behavior aligned to SRS/architecture, and focused unit/integration/contract tests.

Backend track selection

Backend-Track: declares the service role:

Value	Meaning
backend-web	Web-facing backend: public/internal HTTP API, BFF, web gateway, session-backed web API, or API directly serving frontend clients.
backend-service	Microservice/runtime service: domain service, worker, consumer, scheduler, service-mesh API, gRPC service, event processor, or internal integration service.
multiple	More than one backend row exists; select per §3.4.5 Source Layout / architecture container.
N/A	No backend implementation applies.

Framework selection

1. Read docs/SRS.md before inspecting manifests. Headers Backend-Track: and Backend-Framework: are authoritative.
2. If Backend-Framework: is one supported value, select that framework reference.
3. If Backend-Framework: is multiple, select the framework from the §3.4.5 backend row that owns the task's service/container/path. If no row matches or several rows match, halt with NEEDS_CONTEXT and cite the candidate rows.
4. If Backend-Track: is multiple, select the track from the same §3.4.5 backend row. If one framework spans both tracks, the track still controls lifecycle expectations.
5. If either header is N/A, do not perform BE implementation; report that no backend applies.
6. If either header is missing, TBD, unsupported, or inconsistent with §3.4.5, halt and return the work to BA:
   • greenfield/authored SRS: BA Phase 1.X must ask the user to choose;
   • brownfield/extracted SRS: BA Mode E must detect from source evidence and write the SRS fields.
7. After selecting the reference, inspect manifests/source only as a consistency check. If code evidence contradicts the SRS-selected track/framework, halt and raise an open issue; do not silently switch references.