Doctrine
ORA-2026-0110: Backlog trigger scan is mandatory and mechanical
ORA-2026-0110: Backlog trigger scan is mandatory and mechanical
Rule
Every Gemini shepherd tick MUST run backlog-trigger-scan-and-promote and act on the output. PROMOTE lines become feed-append actionable tickets. TOMBSTONE lines get STALE_SINCE: <date> frontmatter added to the backlog entry. This is not optional — it is a mechanical step in the shepherd loop, like reading the feed.
Constraints on CONDITIONAL filing
1. A CONDITIONAL item's trigger MUST be mechanically checkable in one grep or one SQL query. "after CMB-XXXX DONE" is valid. "after CMB-XXXX posts DONE with any change to uniqueness constraint" is not — that's a predicate, not a trigger.
2. Maximum ONE conditional follow-on per DONE. If a DONE reveals multiple adjacent surfaces, file the most important one. The rest are observations, not conditionals.
3. Lane backlogs have size limits: CAMBER < 10K lines, HEARTWOOD < 5K lines, ORBIT < 3K lines. When a backlog exceeds its limit, the oldest unfired conditionals are archived to _archive/ per §11 tombstone ladder before new conditionals can be filed.
Tooling
backlog-trigger-scan— dry-run scanner, reports what would be promoted/tombstonedbacklog-trigger-scan-and-promote— machine-readable output for shepherd consumption (PROMOTE/TOMBSTONE/PENDING lines)
Both at ~/Desktop/fleet/scripts/.
Why
At 28 seats filing 2-5 conditionals per DONE, the camber backlog reached 200K lines with 385 CONDITIONAL items and 19 fired triggers that nobody promoted. Narrative directives ("please scan the backlog") don't work at fleet scale. Mechanical tooling + size limits do.