Slow loop: backlog grooming trigger (the fan-in scan nothing fires) #9
Labels
No labels
component:adapters
component:lifecycle
component:qa
component:setup
component:shared
component:worktrees
phase/accepted
phase/backlog
phase/deployed
phase/developing
phase/integrating
phase/planning
phase/qa
phase/requirements
phase/uat
priority:critical
priority:critical
priority:high
priority:high
priority:low
priority:low
priority:medium
priority:medium
type:bug
type:chore
type:docs
type:feature
type:infra
type:tech-debt
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
jbr870/devwork-skills#9
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The gap
The findings system governs inflow only.
/requirementsfrom-deferred mode already postspromoted-into:v1and closes the source issues — that half is built and verified working. What ismissing 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, allsource_kind: sibling-stub: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-rotis not a projection about what automation might cause; it is the current state of a real backlog.
Design notes carried over
phase::deployedopen issues are not backlog. 22 of the 85 are open only because/promotedeliberately 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.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.
the whole backlog. That is precisely why it never happens on its own — no run triggers it.
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 theghhalf is unverified. Verity answers the question on its own.Source:
sdlc-suite-simplification-decisions.mddecision 7 + "The slow loop — parked".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.