Scope Matched Implementation
Implementation matches the task's actual scope per SBX governance, clean code standards, security NFRs, and applicable workload. Build what is required — fully and properly. Skip what is not required. The balance is the work.
Tags
Overview
Purpose
Implementation matches the task's actual scope per SBX governance, clean code standards, security NFRs, and applicable workload. Build what is required — fully and properly. Skip what is not required. The balance is the work.
Rules
SMI-001: Before adding ANY feature, identify the SPECIFIC requirement that demands it: a user story, decision record, governance rule, security NFR, applicable workspace standard, or measured workload metric. No traceable source → out of scope for THIS task.
Implementation effort traces to requirements. Untraceable features become maintenance burden without delivering value. The trace IS the design audit.
Verification: Each non-trivial design choice in plan or code cites its source explicitly: 'required by [story ref / rule id / NFR / standard / metric]'.
SMI-002: Do NOT skip features that ARE required by applicable governance, security, or NFRs — even when the task feels small. Do NOT add features that are NOT required for THIS task — even when they feel like 'good engineering' in general.
Both extremes fail. Under-implementing required features violates SBX standards. Adding non-required features wastes effort and accumulates maintenance debt. The discipline is matching scope precisely on both directions.
Verification: Run `sbx requirements list --task <id>` to enumerate applicable NFRs. Every applicable NFR has an implementation; every implementation has a traceable requirement.
SMI-003: Defensive measures (cache, rate-limit, audit log, optimistic concurrency, transactional isolation, etc.) are MUSTS where the workload, security model, compliance scope, or governance demands them — and they must be built PROPERLY to the relevant standard. They are SKIPS where THIS task's scope does not require them. The decision is per-feature, per-workload, per-context, never blanket.
Each defensive measure exists to solve a specific class of problem. Where the problem exists in the task scope, the measure must be built correctly to spec. Where the problem is absent from the scope, the measure adds complexity without delivering value.
Verification: Each defensive measure (or its deliberate absence) names the specific NFR / workload metric / threat model / governance rule that justified the decision. 'It seemed like a good idea' is not a valid justification.
SMI-004: When a feature IS required, build it properly to standards — coding-standard, security-checklist, NFR audit, and applicable workspace guidelines. Half-measures and quick hacks violate the standards just as surely as over-building does.
The principle is not 'minimum effort' — it is 'matched effort'. Where caching is required, build the caching layer correctly. Where audit is required, build the immutable audit table with proper grants. Where rate-limiting is required, build per-actor sliding window with logged 429s. The bar is correctness for the actual scope, not skimping under the banner of 'simplicity'.
Verification: Required features pass the verification criteria of every applicable standard — not just 'works on happy path'. Run `sbx knowledge get coding-standard`, `sbx knowledge get auth-security-test-matrix`, `sbx requirements audit --task <id>`.
SMI-005: Match the existing code base — naming, layering, error patterns, logging conventions, package boundaries, test structure. New code reads like existing code in the same area.
Consistency reduces cognitive load and is itself documentation. Patterns that diverge from neighbors force every future reader to context-switch and reverse-engineer the deviation.
Verification: Code review confirms new code follows the closest neighbor's patterns. When uncertain, `sbx knowledge get coding-standard` is the canonical source.
SMI-006: Re-validate scope-match at every SDLC step. Each step completion includes a 1-line drift check: 'still scope-matched? <yes / concrete drift reason / simplification made>'.
Scope drift compounds silently. A feature added 'while I was there' at step 2 is exponentially harder to challenge at step 12 when handlers, tests, view-models, and UI all reference it.
Verification: Step completion notes include the drift-check line; reviewers grep for 'scope-matched', 'simplified', 'dropped', 'added because' as evidence of active validation.
SMI-007: Eager-load only data that EVERY reasonable render of the page actually uses. Per-row counts, conditional fields, history, sample rows, modal-only data belong on dedicated endpoints invoked at the moment the user triggers the action that needs them.
Pre-loading data that's only used in modal X for action Y wastes a query and bandwidth on every page load — for a feature only triggered on click. Deferring to the moment the data matters is the natural shape of REST.
Verification: View-model fields are needed by every render; sometimes-used data lives on a separate endpoint with a clear use-case trigger.
SMI-008: Endpoint count: merge endpoints that share domain + resource + security model when REST semantics permit. PATCH with field change is the standard pattern; separate POST /verb endpoints are warranted only when the action has a distinct security model, distinct response shape, or distinct side effects.
Endpoint proliferation multiplies test surface, auth checks, route handlers, documentation entries, and contract drift surface. REST conventions exist to reduce this.
Verification: Each new endpoint has a distinct resource, security model, OR response shape — not just a different verb on the same resource.
SMI-009: Migrations: only when THIS task's required schema demands them. Adding columns 'for future flexibility' is out of scope until a concrete story or NFR needs them.
Each migration adds deployment risk (ordering, rollback paths, multi-instance coordination) and maintenance cost. Speculative columns add query weight, validation surface, and review burden without delivering value.
Verification: Each migration names the specific story / NFR / standard that fails without it.
SMI-010: Component count: match UI fragmentation to concrete reuse. Group affordances into fewer components until extraction is demanded by a second consumer or by a clear plan for one.
Component fragmentation introduces prop drilling, file count, import noise. Aspirational reuse is over-engineering; concrete reuse is the trigger for extraction.
Verification: Each new component has distinct logic AND is invoked from multiple call sites OR has a concrete plan for multiple call sites.
SMI-011: When in doubt about scope, the default is 'show me the trace'. The plan, the page-model, the migration, the handler must each cite a specific source: story ref, decision record, governance rule, security NFR, applicable standard, or measured workload.
Hypothetical requirements drive anticipatory engineering. Concrete sources drive right-sized implementation. The trace is a 1-line citation, not a paragraph of justification.
Verification: Plan + code reference the specific source for each non-trivial design choice. Reviewers can follow the citations to the source artifact.
SMI-012: Out-of-scope items are documented explicitly with a deferral target: a future task name or 'when X concrete demand exists'. Out-of-scope is not 'we don't care' — it's 'we know this exists, it's not for now, here is when to revisit'.
Explicit deferral preserves institutional knowledge. When the future arrives, the task name + condition tells the reader exactly what was anticipated and why it waited.
Verification: Plan section §out-of-scope lists items with future-task references or concrete deferral conditions.