Slow loop: backlog grooming trigger (the fan-in scan nothing fires) #9

Open
opened 2026-08-11 14:55:44 +00:00 by jbr870 · 1 comment
Owner

The gap

The findings system governs inflow only. /requirements from-deferred mode already posts
promoted-into:v1 and closes the source issues — that half is built and verified working. What is
missing is the trigger: nothing surveys the backlog and proposes "these five stubs are one
feature."
Every skill in the suite is scoped to one feature issue; nothing looks across issues.

Evidence (fact-find, 2026-08-11)

Scanned verity's notes for promoted-into:v1. Three well-formed records exist, all 2026-08-05, all
source_kind: sibling-stub:

Source → Target Rationale (abridged)
#152 #154 the ordered-read contract became an AC on the absorbing feature
#165 #167 edit/delete — "the message-mutation half of the lifecycle"
#166 #167 conclusion-on-resolve — shares the permission and display model

The round trip is complete, not just the comment — each source closed within ~10 seconds of its
record being posted, both targets open. So the emitting half is exercised code; this would not be
built on an untested mechanism.

The volume is the actual finding. Three promotions against 55 open issues at phase::backlog
25 created before 2026-07, oldest 2026-06-10. Full open distribution: backlog: 55, deployed: 22,
developing: 4, planning: 3, requirements: 1. The mechanism works and nothing fires it. Defer-rot
is not a projection about what automation might cause; it is the current state of a real backlog.

Design notes carried over

  • phase::deployed open issues are not backlog. 22 of the 85 are open only because /promote
    deliberately never closes an issue — closing is a separate human act. A scan treating "open" as
    "outstanding" will mis-count them. The target population is phase::backlog.
  • The need is served by hand when nothing automates it. verity #46 (2026-06-19) carries a prose
    note — "it'll be closed as promoted-into #43" — a human doing the mechanism manually, two months
    before the schema existed. Demand signal, not noise.
  • Different clock. Everything else in the suite runs per feature run; this runs periodically over
    the whole backlog
    . That is precisely why it never happens on its own — no run triggers it.
  • Possibly one skill with the periodic process review (see the sibling issue): both are periodic
    cross-run readers of the same artifact trail.

Not scanned

outwrit (github.com/neddes/outwrit) 404s for the account on the box where the fact-find ran, so the
gh half is unverified. Verity answers the question on its own.

Source: sdlc-suite-simplification-decisions.md decision 7 + "The slow loop — parked".

## The gap The findings system governs **inflow** only. `/requirements` from-deferred mode already posts `promoted-into:v1` and closes the source issues — that half is built and **verified working**. What is missing is the **trigger**: nothing surveys the backlog and proposes *"these five stubs are one feature."* Every skill in the suite is scoped to one feature issue; nothing looks across issues. ## Evidence (fact-find, 2026-08-11) Scanned verity's notes for `promoted-into:v1`. **Three well-formed records exist**, all 2026-08-05, all `source_kind: sibling-stub`: | Source | → Target | Rationale (abridged) | |---|---|---| | #152 | #154 | the ordered-read contract became an AC on the absorbing feature | | #165 | #167 | edit/delete — "the message-mutation half of the lifecycle" | | #166 | #167 | conclusion-on-resolve — shares the permission and display model | **The round trip is complete, not just the comment** — each source closed within ~10 seconds of its record being posted, both targets open. So the emitting half is *exercised code*; this would not be built on an untested mechanism. **The volume is the actual finding.** Three promotions against **55 open issues at `phase::backlog`** — 25 created before 2026-07, oldest 2026-06-10. Full open distribution: `backlog: 55`, `deployed: 22`, `developing: 4`, `planning: 3`, `requirements: 1`. The mechanism works and nothing fires it. Defer-rot is not a projection about what automation might cause; it is the current state of a real backlog. ## Design notes carried over - **`phase::deployed` open issues are not backlog.** 22 of the 85 are open only because `/promote` deliberately never closes an issue — closing is a separate human act. A scan treating "open" as "outstanding" will mis-count them. The target population is `phase::backlog`. - **The need is served by hand when nothing automates it.** verity #46 (2026-06-19) carries a *prose* note — "it'll be closed as promoted-into #43" — a human doing the mechanism manually, two months before the schema existed. Demand signal, not noise. - **Different clock.** Everything else in the suite runs *per feature run*; this runs *periodically over the whole backlog*. That is precisely why it never happens on its own — no run triggers it. - Possibly one skill with the periodic process review (see the sibling issue): both are periodic cross-run readers of the same artifact trail. ## Not scanned outwrit (`github.com/neddes/outwrit`) 404s for the account on the box where the fact-find ran, so the `gh` half is unverified. Verity answers the question on its own. *Source: `sdlc-suite-simplification-decisions.md` decision 7 + "The slow loop — parked".*
Author
Owner

Sibling of #10 — both are periodic cross-run readers of the same artifact trail, on the same clock. Decision 7 notes they may well end up as one skill; worth deciding that once one of them is being built rather than up front.

Sibling of #10 — both are periodic cross-run readers of the same artifact trail, on the same clock. Decision 7 notes they may well end up as one skill; worth deciding that once one of them is being built rather than up front.
Sign in to join this conversation.
No description provided.