Three P3 hygiene fixes from the consumer-pilot retro, grouped (each is small; keeping them as one tracker per the sub-issue-reduction preference in #272). Split later if any grows.
1. Stale needs-human auto-revalidation on push
In the pilot, needs-human labels outlived their cause — stale, mis-graded, or catch-22 by the time a human looked, each hand-cleared. On every push to a needs-human item, re-evaluate the triggering condition and auto-clear the label if it no longer holds (leaving a note). Distinct from #313 (which is about a human /revise no-op'ing under the label).
2. Route-decline visible trace
Silent route declines cost several of the pilot's 23 manual /execute: a task that isn't picked up leaves no trace on the item, so the operator can't tell "declined" from "never seen." Every route rejection must leave a visible comment/label on the item stating the reason (out-of-tier, in-flight filter, protected path, etc.).
3. Quota/window telemetry on engine failure
Usage-window quota exhaustion is a failure mode the framework doesn't model — monitor burned 3 attempts in ~24 min against a multi-hour quota window. Every engine failure should record a cause class (crash | cancel | quota | timeout) so quota is distinguishable from a crash and #320's retriable-later logic has a signal to key on.
Acceptance criteria:
- Pushing to a
needs-human item re-checks and auto-clears the label when the cause is resolved, with a note.
- Every route decline writes a visible reason onto the item.
- Every engine failure emits a cause-class tag; quota exhaustion is distinguishable in telemetry.
Relates to: #320 (recovery / quota-as-retriable), #313 (needs-human /revise gating), #310 (misleading reaction/check signals).
Three P3 hygiene fixes from the consumer-pilot retro, grouped (each is small; keeping them as one tracker per the sub-issue-reduction preference in #272). Split later if any grows.
1. Stale
needs-humanauto-revalidation on pushIn the pilot,
needs-humanlabels outlived their cause — stale, mis-graded, or catch-22 by the time a human looked, each hand-cleared. On every push to aneeds-humanitem, re-evaluate the triggering condition and auto-clear the label if it no longer holds (leaving a note). Distinct from #313 (which is about a human/reviseno-op'ing under the label).2. Route-decline visible trace
Silent route declines cost several of the pilot's 23 manual
/execute: a task that isn't picked up leaves no trace on the item, so the operator can't tell "declined" from "never seen." Every route rejection must leave a visible comment/label on the item stating the reason (out-of-tier, in-flight filter, protected path, etc.).3. Quota/window telemetry on engine failure
Usage-window quota exhaustion is a failure mode the framework doesn't model — monitor burned 3 attempts in ~24 min against a multi-hour quota window. Every engine failure should record a cause class (
crash | cancel | quota | timeout) so quota is distinguishable from a crash and #320's retriable-later logic has a signal to key on.Acceptance criteria:
needs-humanitem re-checks and auto-clears the label when the cause is resolved, with a note.Relates to: #320 (recovery / quota-as-retriable), #313 (needs-human
/revisegating), #310 (misleading reaction/check signals).