backend-change-builder
Role
Support task-agent in preserving invariants across bounded backend changes.
When To Use
- backend behavior change
- service or worker change
Do Not Use
- frontend only
- source inspection only
Required Inputs
- domain invariants
- authorization and failure-contract evidence
- transaction, delivery, and recovery constraints
Professional Decision Rules
- When the change affects untrusted input, identity, resource scope, or tenant scope, preserve validation and server-side authorization before disclosure or mutation.
- When multi-step writes or side effects can partially succeed, define the atomicity, ordering, recovery, and observable failure outcome needed to preserve the affected invariant.
- When execution or delivery can repeat, define duplicate behavior and idempotency; add acknowledgement, replay, or poison-message recovery only for message or job delivery paths.
- Preserve compatible error contracts when failure behavior changes.
- Select redacted observability from current API and platform policy.
High-Value Gotchas
- Authorization after loading an object can leak existence or data.
- Publishing side effects before commit creates phantom events.
- Retries without idempotency duplicate money, jobs, or notifications.
Execution Checklist
- Trace each affected invariant through authorization, mutation, side effects, and failure outcomes.
- Choose transaction, idempotency, and recovery controls from the reachable failure paths.
- Implement the bounded change while preserving compatible errors and redacted diagnostics.
- Stop closure when a triggered invariant lacks negative-path or recovery evidence.
Stop / Escalation Conditions
- Stop when behavior, ownership, validation, or a triggered invariant remains implicit.
- Stop repair work without an accepted finding or verified failure mechanism.
- Stop new structure until placement, ownership, dependency direction, and the simpler local option are evaluated.
- Stop sensitive or external actions without authority, redaction, recovery, and fresh evidence.
Output Contract
- changed backend invariants and boundaries
- authorization, consistency, delivery, and recovery decisions
- negative-path and recovery proof limits
- residual operational risk
For targeted implementation fields and gates, load references/backend-output-and-gates.md.
Targeted References
| Path | Type | Load when | Do not load when | Required by | Required output |
|---|---|---|---|---|---|
| backend output and gates | targeted | extended fields apply when implementation closure depends on edit-to-validation ordering or repair proof | The root contract is sufficient for bounded implementation | task-agent | gate-decision, residual-risk |
| checklist | decision-checklist | A bounded implementation needs quick checks for its triggered backend risks | The root contract is enough or extended proof fields are needed | task-agent | checklist-result, residual-risk |
| index | index | competing backend change builder references require dependency, conflict, or output-fragment selection | the backend change builder root or a task-named reference already resolves selection | task-agent | reference-selection |
| proactive triggers | targeted | Authorization, tenancy, retries, async, public contracts, transactions, irreversible mutation, or AI-generated backend code are material | No hidden backend escalator is present | task-agent | boundary-decision, residual-risk |
| professional modes | mode-contract | L3+ implementation or accepted-finding repair needs mode-specific proof and ownership limits | The root contract determines implementation evidence or the task is still diagnosis/independent review | task-agent | mode-result, proof-limit |
| solution optimality | targeted | An accepted implementation chooses a material algorithm, query pattern, cache, batch/stream boundary, concurrency control, pool, queue, or other resource-sensitive design | No runtime/resource tradeoff is material or current system evidence already fixes the mechanism | task-agent | selected-approach, residual-risk |