Two specs, one job: keep GitHub Project boards matching reality with only safe,
bounded, reversible writes. One pushes from inside the session; the other reconciles from a
durable schedule between sessions. Neither alone closes the loop.
The loop
In-session · push
Session → Board Trail
metis spec · reconcile-session-to-board
Fires inside a live session — ~20% context hook · /board-sync · /end parity
Agent-authored: judgment over what happened (priority framing, close-vs-keep)
Writes the trail at session boundaries
⚠ Blind after session close — a CI-merged PR at 2am is invisible to it.
↘ ↗
write
Between-session · reconcile
Scheduled Board Sweep
viska-pm spec · launchd tick on K20N0S
Fires on a durable schedule — survives session close + reboot (7,37 9-18 * * 1-5)
No LLM in the hot path — deterministic, evidence-driven writes only
Catches exactly the window the push half can't see
⚠ No judgment — escalates priority/dispatch to a one-line operator prompt.
↓↓
GitHub Project boards
the shared work-state SSOT · both write only via App token, both idempotent, both bounded
Why both — coverage division
Only the push half catches
What I did this session before anything's committed; the framing/judgment a deterministic script can't infer.
Only the tick catches
Drift while no session is open — a PR merged by CI after close, an issue closed elsewhere. Structurally invisible to an in-session hook.
Together
Full coverage. Judgment-in-session + deterministic-between-sessions. Both idempotent, so where they overlap they reinforce, never fight.
The proof — Viska-PM field test (read-only, today)
Read-only sweep is performing well
Judged against actual board state, not self-report: 126 items / 31 Done / 15 In-Progress / 80 Todo — matches reality, no fabricated state.
accuratelow-noisedisciplined
Caught handoffs 9→10→11, the conviction-p2 stream, CF-Access caveats; held the "surface only NEW-urgent" rule. Signal/noise discipline — the hard part — is holding.
…but it's a mirror, not a janitor
[VISKADB] Stjórnbord CIO demo CF hosting
title: DONE 2026-06-11 · board: still Todo · 6 days cold
[DEMO] stjornbord SPA v2
title: SHIPPED 2026-06-11 · board: still Todo · 6 days cold
The sweep sees these every run but is barred from writing Status=Done.
2 confirmed; a slice of the 80 Todo (63%) is done-but-unsynced. A read-only mirror can't tell which, or fix it.
This is Phase B(1).
The bounded writes — what each half is allowed to do
Viska-PM tick — Phase B
deterministic · evidence-driven · no LLM
1
Status → Done— linked PR MERGED or issue CLOSED
2
Status → In Progress— open PR or commit refs it, was Todo
3
New-work intake— untracked → draft Triage card, no Priority, no Agent
4
Stale flag— Todo/In-Progress untouched >14d → one-line stale? comment
C
Escalate— anything judgment → operator one-liner. Never dispatch/reprioritize/delete/merge.
They share a write-vocabulary, guardrails, and the board SSOT. Ship as two specs that cross-reference (metis owns push, viska-pm owns tick), or unify into one "board-truth keeper" with two runtimes?
▸ Recommend: two coordinated specs, one shared guardrail appendix. Different owners, machines, runtimes — forcing one spec couples them artificially.
D2 · Viska-PM Phase B autonomy on day one
Ship all 4 mechanical writes live, or start with Status-sync (1+2) only and add intake/stale after a week of dry-run?
▸ Recommend (matches viska-pm's own): status-sync first — safest, highest-value, fully reversible; it fixes the 2 stale items immediately.
D3 · fleet generalization
Viska-PM's tick is viska-specific (launchd on K20N0S, vpmgh). Is the pattern per-constellation ticks, or one atlas-owned fleet sweep? This is Class C / project-ops — Hephaistos + Athena territory.