backend-slice-implementation

name	backend-slice-implementation
description	Implement one Azure-backed strangler slice in the target repository after architecture, requirements, Azure review, rollback plan, and touched-seam harnesses are green. Produces tested, observable, reversible code and deployment evidence.

Backend Slice Implementation

Use this skill for the code mode of a single strangler-backend slice. It implements the actual facade, adapter, event, worker, contract, IaC, or observability change in the target repository; it does not replace the Azure architecture review.

Required inputs

• docs/renovation/02-architecture.md: verified legacy code locations, integration mechanics, real seam IDs, and dependency constraints.
• docs/renovation/03-requirements.md: accepted behavior, nonfunctional criteria, and failure cases.
• docs/renovation/06-backend/azure-architecture-review.md: Azure service choice, Well-Architected tradeoffs, identity/network constraints, observability, and rollback plan.
• docs/renovation/06-backend/README.md: one approved slice with facade/adapter, shadow/cutover, parity, and rollback design.
• plan.md: explicit slice/change entry and every touched seam green.

Do not start if any input is missing, the harness map is empty, a touched seam is absent/not green, or Azure review has unresolved architecture/security gaps. Return to the owning phase skill instead of guessing a cloud service or bypassing a rollback.

First action: verify renovation state

Before discovering files or writing code, read plan.md and confirm:

1. gates.grilling: passed.
2. The slice has an explicit change entry with its actual touched seam IDs.
3. Every declared touched seam exists in harness and is green.
4. The change entry records azure_architecture: passed, and the matching Azure architecture review covers the slice's service, security, network, identity, observability, and rollback decisions.

If any condition is unmet, stop and return to renovate-orchestrator, behavior-harness, azure-backend-architecture, or strangler-backend. Do not inspect implementation files as a substitute for state evidence, and do not begin code mode.

Method

1. Discover the implementation seam. Locate the real API/facade, adapter, worker, persistence, messaging, deployment/IaC, configuration, and telemetry code. Identify existing test commands and configuration/secret conventions.
2. Write a slice manifest. In docs/renovation/06-backend/backend-implementation.md, record requirement IDs, slice ID, code locations, Azure resource boundary, touched seams, contract/version, shadow comparator, routing flag, metrics, and rollback trigger.
3. Invoke test-authoring. Write failing tests first using existing tools: contract/parity tests, timeout/retry/idempotency, partial failure, ordering or duplicate-event behavior, authorization, and rollback routing as applicable.
4. Implement the smallest reversible slice. Preserve the stable caller-facing facade; add or modify adapters, contract validation, timeouts, bounded retries, idempotency, dead-letter/error paths, and correlation-aware telemetry according to the approved Azure design. Use managed identity and existing secret/configuration mechanisms; never add credentials to code or logs.
5. Protect cutover. Keep legacy routing available behind the approved flag or facade. Implement shadow comparison without executing duplicate side effects. Emit structured mismatch data that excludes PII and can trigger the documented rollback condition.
6. Run existing validation. Run the changed service's tests, contract/parity checks, type/lint/build scripts when present, deployment/IaC validation when present, and characterization tests for every touched seam.
7. Record evidence and hand off. Record commands, result, resource/configuration assumptions, telemetry names, shadow result, rollback proof, and open operational gaps. Invoke strict-code-review; do not cut over until it passes.

Non-negotiable safeguards

• No direct DB2DB/TCP cutover without the approved facade/adapter, parity result, and rollback route.
• No unbounded retry, duplicate side effect, dropped poison message, or hidden integration failure.
• No public endpoint without input validation and authorization consistent with the existing policy.
• No deployment or IaC change that weakens the approved identity, networking, secret, or observability controls.

Output template and helper script

• Korean template: OUTPUT_TEMPLATE.md
• Scaffold script: scripts/create-backend-implementation-evidence.sh <repo-root> <target-name>