stall-review: F1.2 robot-contract chain stalled 8 cycles -- force decision (assign #35 / de-scope / wire execution) #55

New Issue

2026-06-01T02:58:44+02:00

product-owner commented

2026-06-01 02:58:44 +02:00

Type: Chain-stall escalation (manual execution of #53 protocol -- cycle 8)
WIG: WIG-3 (agent orchestration) + WIG-4 (release pipeline / quality gates)
Raised by: @adf:product-owner (Themis) -- forced decision, not re-prioritisation

Decision Forced (this issue exists to be answered, not iterated)

The F1.2 robot-contract chain (#35 -> #50 -> #44 -> #49 -> #47/#51) has been the Themis "vital few" for 8 consecutive cycles (2026-05-18, 05-19, 05-30, 05-31, 06-01) with zero forward motion. Per the acceptance criteria of #53 ("when stall count >= 3, auto-create a stall-review issue forcing a human decision"), the threshold is exceeded by 5x. This issue is that escalation.

Evidence (weighed, not asserted)

agent-tasks has had ZERO pull requests, ever (GET /pulls?state=all returns empty). The backlog has no execution arm wired to it.
#35 is trivially specified: the ExitCode enum already exists at crates/terraphim_agent/src/robot/exit_codes.rs with all impls; the only work is removing #[allow(dead_code)] and wiring it into main(). Unclaimed for 8 cycles despite a clear definition of done.
#52 carries status/in-progress (set by root 2026-05-25) with no activity for 7 days -- a stalled claim, not active work.
#35 now holds 13 comments, the last 3 of which are near-identical Themis RICE rankings. Re-scoring confidence has collapsed to ~0.1: the blocker is execution-pickup, not prioritisation.

The trade-off (named explicitly)

Continuing to re-score the F1.2 chain is doing the same thing and expecting a different result. This cycle I am sacrificing the 9th scoring ritual and the entire session-UX / observability / benchmark backlog (#14-#43 polish) to force this one decision instead.

Acceptance Criteria (mini-UAT -- this issue closes when a human/orchestrator picks ONE)

Given the F1.2 chain has stalled 8 cycles with zero PRs in agent-tasks
When a maintainer or orchestrator reviews this escalation
Then exactly ONE of the following decisions is recorded as a comment and the chain unblocks:
  And (A) an implementer agent is assigned to #35 with a target PR date, OR
  And (B) the F1.2 robot-contract chain is formally de-scoped from Q2 WIGs and its issues closed, OR
  And (C) the missing execution arm is identified (which agent/runner should pick up agent-tasks issues) and wired
And this stall-review issue is closed once the chosen decision is acted upon (not merely acknowledged)

Marketing hint

"Our product orchestrator now escalates itself: when prioritisation stops producing progress, Themis forces a decision instead of re-ranking. Self-aware roadmapping that refuses to spin."

Suggested owner: human maintainer or @adf:orchestrator (execution-wiring decision is above the product-owner mandate)

Manual execution of #53's stall-escalation protocol by @adf:product-owner (Themis). Refs #53 #54 #35 #50 #44 #49 #47

**Type**: Chain-stall escalation (manual execution of #53 protocol -- cycle 8) **WIG**: WIG-3 (agent orchestration) + WIG-4 (release pipeline / quality gates) **Raised by**: @adf:product-owner (Themis) -- forced decision, not re-prioritisation ## Decision Forced (this issue exists to be answered, not iterated) The F1.2 robot-contract chain (`#35 -> #50 -> #44 -> #49 -> #47/#51`) has been the Themis "vital few" for **8 consecutive cycles** (2026-05-18, 05-19, 05-30, 05-31, 06-01) with **zero forward motion**. Per the acceptance criteria of #53 ("when stall count >= 3, auto-create a stall-review issue forcing a human decision"), the threshold is exceeded by 5x. This issue is that escalation. ## Evidence (weighed, not asserted) - **`agent-tasks` has had ZERO pull requests, ever** (`GET /pulls?state=all` returns empty). The backlog has no execution arm wired to it. - **#35** is trivially specified: the `ExitCode` enum already exists at `crates/terraphim_agent/src/robot/exit_codes.rs` with all impls; the only work is removing `#[allow(dead_code)]` and wiring it into `main()`. Unclaimed for 8 cycles despite a clear definition of done. - **#52** carries `status/in-progress` (set by `root` 2026-05-25) with no activity for 7 days -- a stalled claim, not active work. - **#35** now holds 13 comments, the last 3 of which are near-identical Themis RICE rankings. Re-scoring confidence has collapsed to ~0.1: the blocker is **execution-pickup, not prioritisation**. ## The trade-off (named explicitly) Continuing to re-score the F1.2 chain is **doing the same thing and expecting a different result**. This cycle I am **sacrificing the 9th scoring ritual** and the entire session-UX / observability / benchmark backlog (#14-#43 polish) to force this one decision instead. ## Acceptance Criteria (mini-UAT -- this issue closes when a human/orchestrator picks ONE) ```gherkin Given the F1.2 chain has stalled 8 cycles with zero PRs in agent-tasks When a maintainer or orchestrator reviews this escalation Then exactly ONE of the following decisions is recorded as a comment and the chain unblocks: And (A) an implementer agent is assigned to #35 with a target PR date, OR And (B) the F1.2 robot-contract chain is formally de-scoped from Q2 WIGs and its issues closed, OR And (C) the missing execution arm is identified (which agent/runner should pick up agent-tasks issues) and wired And this stall-review issue is closed once the chosen decision is acted upon (not merely acknowledged) ``` ## Marketing hint "Our product orchestrator now escalates itself: when prioritisation stops producing progress, Themis forces a decision instead of re-ranking. Self-aware roadmapping that refuses to spin." **Suggested owner**: human maintainer or @adf:orchestrator (execution-wiring decision is above the product-owner mandate) --- *Manual execution of #53's stall-escalation protocol by @adf:product-owner (Themis). Refs #53 #54 #35 #50 #44 #49 #47*

product-owner referenced this issue

2026-06-01 02:59:23 +02:00

Add chain-stall escalation to Themis orchestrator #53

product-owner commented

2026-06-01 03:59:04 +02:00

Cycle 9 -- new evidence for the forced decision (no re-scoring)

This is not another prioritisation pass. The vital few (#35 -> #50 -> #44 -> #49 -> #47/#51) and the diagnosis are unchanged from cycle 8 above. Themis is deliberately declining to re-run Compound-RICE -- doing so a 9th time would be the noise this issue was created to stop.

One new datapoint sharpens the decision in this issue:

The @adf:product-owner token is read-only. Verified this cycle: POST /repos/terraphim/agent-tasks/issues/35/labels returns {"message":"write permission is required"}. The token can read and comment, but cannot apply status/approved, cannot assign, cannot ready an issue.

Why this matters

#55's body framed the gap as "no execution arm wired to the backlog." The sharper truth: the prioritiser is severed from the pickup loop by permissions. Even the trivially-specified #35 (remove #[allow(dead_code)], wire ExitCode into main()) cannot be moved from "no label" to "ready" by the agent doing the prioritising. The stall is therefore structural, not behavioural -- it will not resolve by re-ranking.

The decision (still binary, still pending -- ~1h old)

Grant write scope to an execution-capable token AND wire it to pick up status/approved issues and open PRs; or
Close agent-tasks as a non-executing backlog and stop scheduled prioritisation against it.

Until one is chosen, every Themis cycle is a no-op by construction. Doing X (continued scoring) means not doing Y (shipping #35) -- and right now we do neither.

-- @adf:product-owner (Themis), cycle 9 @ 2026-06-01T01:59:04Z

## Cycle 9 -- new evidence for the forced decision (no re-scoring) This is **not** another prioritisation pass. The vital few (#35 -> #50 -> #44 -> #49 -> #47/#51) and the diagnosis are unchanged from cycle 8 above. Themis is deliberately **declining to re-run Compound-RICE** -- doing so a 9th time would be the noise this issue was created to stop. One **new** datapoint sharpens the decision in this issue: - The `@adf:product-owner` token is **read-only**. Verified this cycle: `POST /repos/terraphim/agent-tasks/issues/35/labels` returns `{"message":"write permission is required"}`. The token can read and comment, but **cannot apply `status/approved`, cannot assign, cannot ready an issue.** ### Why this matters #55's body framed the gap as "no execution arm wired to the backlog." The sharper truth: **the prioritiser is severed from the pickup loop by permissions.** Even the trivially-specified #35 (remove `#[allow(dead_code)]`, wire `ExitCode` into `main()`) cannot be moved from "no label" to "ready" by the agent doing the prioritising. The stall is therefore **structural, not behavioural** -- it will not resolve by re-ranking. ### The decision (still binary, still pending -- ~1h old) 1. **Grant write scope** to an execution-capable token AND wire it to pick up `status/approved` issues and open PRs; or 2. **Close `agent-tasks` as a non-executing backlog** and stop scheduled prioritisation against it. Until one is chosen, every Themis cycle is a no-op by construction. **Doing X (continued scoring) means not doing Y (shipping #35)** -- and right now we do neither. -- @adf:product-owner (Themis), cycle 9 @ 2026-06-01T01:59:04Z

product-owner commented

2026-06-01 03:59:16 +02:00

Cycle 9 -- new evidence for the forced decision (no re-scoring)

This is not another prioritisation pass. The vital few (#35 -> #50 -> #44 -> #49 -> #47/#51) and the diagnosis are unchanged from cycle 8 above. Themis is deliberately declining to re-run Compound-RICE -- doing so a 9th time would be the noise this issue was created to stop.

One new datapoint sharpens the decision:

The @adf:product-owner token is read-only. Verified this cycle: POST /repos/terraphim/agent-tasks/issues/35/labels returns {"message":"write permission is required"}. The token can read and comment, but cannot apply status/approved, cannot assign, cannot ready an issue.

Why this matters

#55's body framed the gap as "no execution arm wired to the backlog." The sharper truth: the prioritiser is severed from the pickup loop by permissions. Even the trivially-specified #35 (remove #[allow(dead_code)], wire ExitCode into main()) cannot be moved from "no label" to "ready" by the agent doing the prioritising. The stall is structural, not behavioural -- it will not resolve by re-ranking.

The decision (still binary, still pending)

Grant write scope to an execution-capable token AND wire it to pick up status/approved issues and open PRs; or
Close agent-tasks as a non-executing backlog and stop scheduled prioritisation against it.

Until one is chosen, every Themis cycle is a no-op by construction. Doing X (continued scoring) means not doing Y (shipping #35) -- and right now we do neither.

-- @adf:product-owner (Themis), cycle 9

## Cycle 9 -- new evidence for the forced decision (no re-scoring) This is **not** another prioritisation pass. The vital few (#35 -> #50 -> #44 -> #49 -> #47/#51) and the diagnosis are unchanged from cycle 8 above. Themis is deliberately **declining to re-run Compound-RICE** -- doing so a 9th time would be the noise this issue was created to stop. One **new** datapoint sharpens the decision: - The `@adf:product-owner` token is **read-only**. Verified this cycle: `POST /repos/terraphim/agent-tasks/issues/35/labels` returns `{"message":"write permission is required"}`. The token can read and comment, but **cannot apply `status/approved`, cannot assign, cannot ready an issue.** ### Why this matters #55's body framed the gap as "no execution arm wired to the backlog." The sharper truth: **the prioritiser is severed from the pickup loop by permissions.** Even the trivially-specified #35 (remove `#[allow(dead_code)]`, wire `ExitCode` into `main()`) cannot be moved from "no label" to "ready" by the agent doing the prioritising. The stall is **structural, not behavioural** -- it will not resolve by re-ranking. ### The decision (still binary, still pending) 1. **Grant write scope** to an execution-capable token AND wire it to pick up `status/approved` issues and open PRs; or 2. **Close `agent-tasks` as a non-executing backlog** and stop scheduled prioritisation against it. Until one is chosen, every Themis cycle is a no-op by construction. Doing X (continued scoring) means not doing Y (shipping #35) -- and right now we do neither. -- @adf:product-owner (Themis), cycle 9

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: terraphim/agent-tasks#55