Thin Vertical Slice Methodology

This document is the local nexus process reference for keeping feature work narrow, testable, and reviewable.

The Six Rules

Rule 1: One Narrow End-To-End Path

Each delivery slice picks a single axis of narrowness and proves one working path through the system. Examples include one provider, one endpoint, one event type, one tenant, one policy rule, or one transport mode.

Rule 2: Skeleton-Then-Grow For Shared Surfaces

Crates, proto files, schemas, and service APIs start with the smallest real behavior that the current change needs. Do not add empty modules, unused RPCs, or broad table shapes only because a later change might need them.

Rule 3: No Forward References In Acceptance Criteria

Acceptance criteria must refer only to behavior present in the tree after the change lands. If a criterion needs a missing capability, either include that capability in the current slice or move the criterion to the change that implements it.

Rule 4: Name Deferred Work Explicitly

When work is intentionally out of scope, name the missing capability and the artifact that will grow later. Unowned deferred work is not deferred; it is abandoned.

Rule 5: Add A Non-Regressing Integration Test

Every non-trivial slice adds at least one test that exercises the path end to end. Later changes extend or supersede those tests instead of silently breaking them.

Rule 6: Avoid Hero Numbers

Performance and scale criteria must be measurable and tied to a concrete reference environment. Avoid vague claims such as “fast enough” or implausible thresholds without a reproducible baseline.

Enforcement

• MR descriptions identify the authoritative specification and the narrow behavior implemented.
• Reviewers reject scope that is broader than the cited specification.
• CI and review treat integration tests as the executable definition of done.