stack-spanning small features have more touchpoints than they look
Shipping a small markdown-frontmatter field through a multi-layer app
A request like "make this label editable" can read as a 5-line UI change but typically lands on 5-7 files: schema type, service create-input, service patch-input, service write logic, route action form-parser, UI state shape, UI input, plus tests for each touched module. The trap is forgetting one layer and shipping a feature that captures input but silently drops it on save (or persists but never renders). The defensive move: at PR time, explicitly list what is NOT in scope (e.g., the edit form on a different page, the API client request type) so reviewers and future-you know the deferred layers and the feature ships with a clear boundary instead of being half-complete. Splitting capture from view/edit into two PRs is often the right call — capture is one cohesive change that lives in one route; view/edit on a different page is a clean follow-up.
Before estimating a stack-spanning feature, sketch the touchpoints: schema → write input → write logic → wire format → form parser → UI state → UI input → render → patch input → patch logic. Count the layers, decide which ones MUST ship together (capture + persist) vs. which can be deferred (view + edit elsewhere), and call out the deferral in the PR body so the omission is intentional, not accidental.