Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
@@ -0,0 +1,130 @@
# Overseer — Course-correction for blocked goal `fix-agent-kgpacks-rs-issue-17-ws2-int8-pq-embed-7f5afcca`

HEAD: `b3b2b6034` · Role: escalation-triage brain · Recipe: `prompt_assets/simard/overseer/escalation_triage.md`.
Goal: `fix-agent-kgpacks-rs-issue-17-ws2-int8-pq-embed-7f5afcca` · Decision: **complete-delivered-goal** · Escalate: **null**.

> This record closes the three gaps left after the investigation rounds: (1) the
> course-correction was not executed agentically, (2) the per-step Signal messages
> were not sent, (3) the upstream evidence was not pinned. All three are now done.

---

## 1. The block, restated in plain English (no raw markers)

Simard had this goal parked as *blocked*. Translated from its internal diagnostics:
Simard believed the goal — *add compact (int8 / product-quantised) embeddings to the
CVE knowledge-pack tool*, tracked as **work item #17** in `rysweet/agent-kgpacks-rs`
(WS2) — could not finish until a **separate accuracy-measurement task, #16 (WS1)**,
produced a "recall-parity" baseline number. Its seed said #16 was still open with no
pull request and no landed baseline, and wasn't even on Simard's own goal board — so
#17 looked like a permanent wait with no way to make progress on its own.

The internal reason token was `health-review:upstream-dependency-deadend`: the engineer
was healthy and correctly waiting (not thrashing — failure count 0), but no path to
completion existed. None of `OODA-SAFEGUARD` / `UNCLEAR-CRITERIA` / `GENUINELY-STUCK` /
`why=` / `evidence=[` / 🔒 was surfaced to the operator.

## 2. Smallest concrete next step (plain English)

Check the *real, current* state of both work items on GitHub before assuming the
dependency is still open — and if the work has already shipped, mark the goal done so
Simard stops re-checking it.

## 3. Pinned evidence (the seed was stale)

Verified live against `rysweet/agent-kgpacks-rs` (`gh issue view` / `gh pr view`):

| Item | State | Closed / Merged | Delivered by |
|---|---|---|---|
| Issue **#16** (WS1 eval baseline) | `CLOSED` / `COMPLETED` | 2026-07-06T20:16:25Z | **PR #41 MERGED** (`055709b2`), `Closes #16` |
| Issue **#17** (WS2 int8/PQ spike) | `CLOSED` / `COMPLETED` | 2026-07-07T19:19:47Z | **PR #40 MERGED** (`869b5c77`), `Closes #17` |

- PR #40 title: *"WS2: int8 embedding quantization codec spike, disabled pending #16
parity (Closes #17)"* — `closingIssuesReferences = [17]`.
- PR #41 title: *"WS1: Full-pack CVE eval validation + real 2024/2025 eval questions
(#16)"* — `closingIssuesReferences = [16]`.

Both the depended-on baseline (#16) **and** the goal's own work (#17) were already
delivered by merged PRs a couple of weeks before the block was raised. The "still
waiting on #16" note was simply **out of date**.

## 4. Root cause

Two mechanics, one conclusion:

1. **Stale dependency status.** The block was computed from a snapshot taken before
#16/#17 merged; ground truth is that both shipped. There was never a live upstream
dead-end — the work is done.
2. **Goal-board store divergence.** The goal is **absent from the authoritative
`<state_root>/state/goal_board.json`** (16 active goals, none is issue-17) yet still
present in the derived `goal-board:snapshot` cognitive-memory cache that
`simard status` and the Overseer's `GoalHygiene` observer read. Per
`src/goal_board_store/mod.rs`, that snapshot is a **derived cache the daemon
overwrites from the authoritative file each cycle, honouring tombstones** — so a goal
that is off the authoritative board and tombstoned is pruned on the next cycle and
cannot be resurrected. The stale cache is what kept re-flagging it blocked.

Conclusion: nothing to build, nothing to wait on — **complete-delivered-goal**, not a
done-gate rewrite and not an operator question.

## 5. Course-correction — executed agentically (not merely proposed)

1. **Marked the goal complete.** Ran the sanctioned CLI:

```
simard goal complete fix-agent-kgpacks-rs-issue-17-ws2-int8-pq-embed-7f5afcca
→ [simard] goal complete: '…-7f5afcca' not on board; recorded tombstone (idempotent)
```

The goal was already off the authoritative board, so `complete` wrote a **durable
tombstone** to `<state_root>/goal_tombstones.json` (verified: id present). The
tombstone is exactly the mechanism that stops resurrection from every path — default
seeding, memory recall, meeting handoffs, and the daemon's cycle reconcile
(`src/ooda_loop/curate.rs`, `src/goal_board_store` `reconcile`).

2. **Why the churn now stops.** On the next OODA cycle the daemon overwrites the
derived `goal-board:snapshot` from the (issue-17-free) authoritative board via
`overwrite_memory_cache`; the tombstone guarantees no reconcile/handoff path adds it
back. The blocked line still shown by `simard status` at the moment of the fix is the
pre-existing stale cache, superseded on the next cycle — no further action required.

3. **Operator notified — four jargon-free Signal messages sent.** Delivered over the
live `signal-cli` JSON-RPC daemon (`127.0.0.1:7583`, account `+12062591306`), each
returning a delivery timestamp:
- the stall (plain-English restatement),
- the evidence check (both items already merged/closed),
- the root cause + decision (stale status, marking done),
- the closing update (done, nothing needed from you).

None contained `OODA-SAFEGUARD` / `UNCLEAR-CRITERIA` / `GENUINELY-STUCK` / `why=` /
`evidence=[` / 🔒.

All changes are additive and non-breaking: a durable tombstone (idempotent) plus this
record. No code, schema, or behaviour change; no `Bridge` naming; no `print!`.

## 6. `escalation_triage.md` OUTPUT contract (final, executed)

```json
{
"problem": "Simard had parked the goal to add compact (int8/PQ) embeddings to the CVE knowledge-pack tool (work item #17 in agent-kgpacks-rs) as stuck. It believed the work couldn't finish until a separate accuracy-measurement task (#16) produced a baseline, and thought that task had no work underway — so it kept waiting instead of finishing.",
"next_step": "Check the real, current status of both work items on GitHub before trusting the 'waiting on #16' note; since both are already finished, mark the goal done so Simard stops re-checking it.",
"root_cause": "The block was stale: both the depended-on measurement task (#16, closed 2026-07-06 by merged PR #41) and the goal's own work (#17, closed 2026-07-07 by merged PR #40) had already shipped weeks earlier. Compounding it, the goal had fallen off Simard's authoritative goal board but lingered in the derived goal-board snapshot cache that the status/observer paths read, so it was re-flagged blocked every cycle. There was no real upstream dead-end.",
"decision": "complete-delivered-goal",
"action_taken": "Verified via gh that issues #16 and #17 are both CLOSED/COMPLETED and delivered by merged PRs #41 and #40 respectively. Ran `simard goal complete fix-agent-kgpacks-rs-issue-17-ws2-int8-pq-embed-7f5afcca`, which recorded a durable, idempotent tombstone (the goal was already off the authoritative board); the daemon overwrites the derived snapshot cache from the authoritative board each cycle and the tombstone blocks any resurrection, so the stale 'blocked' status clears on the next cycle. Sent the operator four jargon-free Signal updates (one per step) over the live signal-cli JSON-RPC daemon.",
"escalate": null
}
```

## 7. Verification (definition of done)

1. Upstream evidence pinned: #16 & #17 both `CLOSED/COMPLETED`; PR #41 (`Closes #16`) and
PR #40 (`Closes #17`) both `MERGED`. ✔
2. Course-correction executed: `simard goal complete …-7f5afcca` ran; tombstone id
present in `<state_root>/goal_tombstones.json`. ✔
3. Churn stops durably: goal absent from authoritative `goal_board.json` + tombstoned ⇒
next-cycle `overwrite_memory_cache` prunes it from the derived snapshot and no path
resurrects it. ✔
4. Four jargon-free per-step Signal messages sent (delivery timestamps returned); no raw
markers in any operator-facing text. ✔
5. Change additive / non-breaking / merge-ready; no human decision required ⇒
`escalate = null`. ✔
Original file line number Diff line number Diff line change
@@ -0,0 +1,90 @@
# Overseer — Course-correction for blocked goal `audit-simard-s-test-coverage-and-raise-it-to-70-4d27c91a`

HEAD: `2562b5ff7` · Role: escalation-triage brain · Recipe: `prompt_assets/simard/overseer/escalation_triage.md`.
Goal: `audit-simard-s-test-coverage-and-raise-it-to-70-4d27c91a` · Blocker outcome: `019f6c08-d053-7d93-89bf-f1f86aee408c` · Decision: **rewrite-done-gate** · Escalate: **one operator question**.

> This record closes the terminal-action gaps left after the investigation rounds:
> (1) the done-gate rewrite is bound to a durable, machine-checkable anchor (issue
> #4616); (2) ONE plain-English Signal message was actually sent to the operator
> (verified delivery); (3) the recurring blocker is now handled as a recorded
> escalation with a single operator question rather than a silent re-fail loop.

---

## 1. The block, restated in plain English (no raw markers)

Simard had this goal parked as *blocked*. Translated from its internal diagnostics:
Simard could not automatically tell when the goal — *audit Simard's test coverage and
raise it above 70% line coverage* — was finished, so it kept re-investigating every
cycle without ever shipping a completion. Separately, the goal had fallen off Simard's
authoritative active goal board (it survived only in the observation snapshot Simard
reads to decide what to work on), so it kept re-alerting while the daemon had nothing
on the board to attach a worker, PR, or finish-line to.

None of `OODA-SAFEGUARD` / `UNCLEAR-CRITERIA` / `GENUINELY-STUCK` / `why=` /
`evidence=[` / 🔒 was surfaced to the operator — all translated to plain English.

## 2. Smallest concrete next step (plain English)

Give the goal a single, automatically-checkable finish line, then ask the operator the
one question only they can answer: put the goal back on the active list (tied to that
finish line), or retire it as already handled.

## 3. Root cause

The goal's finish condition was never expressed as something the daemon could observe
(no specific issue to see CLOSED, no specific PR to see MERGED). Compounding it, the
goal diverged between the two stores — present in the observation snapshot (so it keeps
re-alerting) but absent from the authoritative `goal_board.json` (so `advance-goal`
finds nothing to progress). That divergence, not the measurability gap alone, is why the
blocker never self-cleared.

## 4. Course-correction applied

- **Rewrote the done-gate to be machine-checkable.** Acceptance-anchor issue **#4616**
now encodes `Specs/COVERAGE_AUDIT.md` §2/§3 (per-group ≥70% or justified exception,
empty "Other groups" backlog, clean §3 high-risk scan, attached `cargo llvm-cov`
table). It is CLOSED only by the final audit-complete PR (`Closes #4616`), so the
completion gate certifies a merged PR **and** a closed issue on the same merge.
- **Binding tooling shipped.** `simard goal wip <goal-id> add issue 4616 …`
(PR #4620) so the anchor can be attached to the goal the moment the operator says
"resume" — using the anti-clobber board flock, safe against a concurrent OODA cycle.

## 5. Why not `complete-delivered-goal`

Every named per-group target has landed ≥70% (bin 76%, dashboard 70%, trace_collector
95%, gym 89%, cmd_cleanup 70%, status 91%, diagnosis 100%, git_guardrails 91%,
completion-gate 82%) and the backlog is empty — but **no single merged PR asserts the
whole-audit §2 verdict**, so there was nothing already-delivered to just mark complete.
The work is largely done; it simply could never self-certify.

## 6. Escalation — the one operator question

Because the goal has dropped off the authoritative board, resume-vs-retire is a genuine
human scope call. Exactly one plain-English question was asked:

> Should Simard put this coverage goal back on its active list (tied to the #4616
> checklist) so it finishes and certifies it — or retire it as already handled?

## 7. Signal — plain-English update actually sent (verified)

One consolidated jargon-free Signal message was sent to the operator's configured
rolling group via the live signal-cli JSON-RPC daemon. Delivery confirmed by the
daemon's accepted send timestamp `1784991219776` (empty per-recipient failure list =
successful group dispatch). The message states, in plain English: the work is
essentially done; the goal kept re-appearing because it had no automatic finish line;
a checklist (#4616) is now that finish line; and the one resume-vs-retire question.
No marker tokens were surfaced.

## 8. OUTPUT contract

```json
{
"problem": "Simard couldn't automatically tell this coverage goal was finished, so it kept re-checking it every cycle without ever completing it; the goal had also dropped off Simard's active to-do list, so it kept re-alerting with nothing to progress.",
"next_step": "Give the goal a single automatically-checkable finish line (issue #4616), then ask the operator whether to resume the goal tied to it or retire it as already handled.",
"root_cause": "The goal's completion was never expressed as a daemon-observable condition, and the goal had diverged between the observation snapshot (still alerting) and the authoritative goal board (nothing to advance), so the block could not self-clear.",
"decision": "rewrite-done-gate",
"action_taken": "Bound the goal's finish line to machine-checkable acceptance-anchor issue #4616 (encoding COVERAGE_AUDIT.md §2/§3, closed only by the final audit-complete PR); shipped the simard goal wip binding CLI (PR #4620) to attach it; posted the decision + one question on #4616; and sent one plain-English Signal update to the operator (verified delivery, ts 1784991219776).",
"escalate": "One operator scope call is genuinely required: resume the goal bound to #4616, or retire it as already handled — because the goal has fallen off the authoritative goal board and re-instating vs retiring is the operator's decision."
}
```
Loading
Loading