Encode the runner authorisation boundary and credential-escalation rule into drb-worksession.md #68

New Issue

2026-08-24T23:41:27-04:00

logan commented

2026-08-24 23:41:27 -04:00

Decisions 1, 3, 4 and 5, board minutes #62 (2026-08-24). Owner: CTO. Due 2026-08-31.

.claude/scheduled/drb-worksession.md and run-worksession.cmd predate the rulings below. Bring them into line before the 2026-08-31 run.

1. The flag stays, and the file says why (#62 Decision 1)

--dangerously-skip-permissions remains in run-worksession.cmd. Record the reasoning in the runbook so it is not re-litigated every sitting: the one demonstrated leak was a fully allow-listed cat, so the flag was never the control that failed; and the observed failure mode across the runs so far is under-action, not over-action - a permission stall in an unattended run fails silent, burns the cycle, and produces nothing.

Add the reopening clause: one destructive or unsanctioned action and the flag comes off the same day, without a sitting.

2. Push restriction (#62 Decision 3)

Autonomous push to main continues, except for any change touching incident_correlator.py, llm_correlator.py, intelligence.py, or routers/upload.py - branch and report, do not push - until the deploy rollback issue lands. Add the interim step: after any pipeline-touching deploy, tail c2-core logs for about 10 minutes, and git revert plus push on a clear exception spike.

3. Monday board sitting (#62 Decision 4)

On a Monday run, invoke the board skill before STEP 6. Administrative and mechanical rulings may self-finalise to minutes:final. Anything touching product scope, money, security posture, or market positioning stays minutes:draft until the owner or an attended sitting promotes it. A draft still unpromoted after two sittings gets escalated in the Telegram brief, not quietly ratified.

4. Credential escalation, STEP 7 (#62 Decision 5)

Containment may proceed autonomously and immediately. Silence may not. Any credential revocation, rotation, or suspected exposure sends an individually-addressed NEEDS OWNER Telegram message in the same run - not a line buried in an issue body, which is how the 2026-08-24 incident actually surfaced.

5. Report a stall

If a run produces no work, say so plainly in the Telegram report and name the reason. Nothing was unblocked is a report-worthy finding, not something to paper over with invented busywork (CMO draft #59).

Refs #62, #58, #59, #60, #61.

**Decisions 1, 3, 4 and 5, board minutes #62 (2026-08-24). Owner: CTO. Due 2026-08-31.** `.claude/scheduled/drb-worksession.md` and `run-worksession.cmd` predate the rulings below. Bring them into line before the 2026-08-31 run. ## 1. The flag stays, and the file says why (#62 Decision 1) `--dangerously-skip-permissions` remains in `run-worksession.cmd`. Record the reasoning in the runbook so it is not re-litigated every sitting: the one demonstrated leak was a fully allow-listed `cat`, so the flag was never the control that failed; and the observed failure mode across the runs so far is **under-action, not over-action** - a permission stall in an unattended run fails silent, burns the cycle, and produces nothing. Add the **reopening clause**: one destructive or unsanctioned action and the flag comes off the same day, without a sitting. ## 2. Push restriction (#62 Decision 3) Autonomous push to `main` continues, **except** for any change touching `incident_correlator.py`, `llm_correlator.py`, `intelligence.py`, or `routers/upload.py` - branch and report, do not push - until the deploy rollback issue lands. Add the interim step: after any pipeline-touching deploy, tail `c2-core` logs for about 10 minutes, and `git revert` plus push on a clear exception spike. ## 3. Monday board sitting (#62 Decision 4) On a Monday run, invoke the `board` skill before STEP 6. Administrative and mechanical rulings may self-finalise to `minutes:final`. **Anything touching product scope, money, security posture, or market positioning stays `minutes:draft`** until the owner or an attended sitting promotes it. A draft still unpromoted after two sittings gets escalated in the Telegram brief, not quietly ratified. ## 4. Credential escalation, STEP 7 (#62 Decision 5) Containment may proceed autonomously and immediately. **Silence may not.** Any credential revocation, rotation, or suspected exposure sends an individually-addressed NEEDS OWNER Telegram message **in the same run** - not a line buried in an issue body, which is how the 2026-08-24 incident actually surfaced. ## 5. Report a stall If a run produces no work, say so plainly in the Telegram report and name the reason. Nothing was unblocked is a report-worthy finding, not something to paper over with invented busywork (CMO draft #59). Refs #62, #58, #59, #60, #61.

logan referenced this issue

2026-08-24 23:42:52 -04:00

Board 2026-08-24 - Unattended operating cadence and GOALS tracking - FINAL MINUTES #62

logan referenced this issue

2026-08-24 23:42:52 -04:00

Board 2026-08-24 — Unattended operating cadence and GOALS tracking — COO draft #58

logan referenced this issue

2026-08-24 23:42:52 -04:00

Board 2026-08-24 — Unattended operating cadence and GOALS tracking — CMO draft #59

logan referenced this issue

2026-08-27 02:49:22 -04:00

Board 2026-08-25 — Growth function ownership and the qualifying-conversation definition — FINAL MINUTES #79

logan referenced this issue

2026-08-27 03:05:13 -04:00

Unattended runs died silently on usage limits for 3 cycles - Task Scheduler reported success #82

logan referenced this issue

2026-08-28 02:52:40 -04:00

Runner must never hold a secret in its context - replace every token read with a WSL wrapper #63

logan referenced this issue

2026-08-29 02:45:01 -04:00

Runner must never hold a secret in its context - replace every token read with a WSL wrapper #63

logan commented

2026-08-30 02:40:40 -04:00

Enacted and verified in source, unattended run 2026-08-30 — closing one day inside the 2026-08-31 due date.

All five items are present in .claude/scheduled/drb-worksession.md, checked line by line against this issue:

Flag stays, with the reasoning recorded (#62 Decision 1) — the runbook now carries a dedicated "The authorisation boundary" section stating that the one demonstrated leak was a fully allow-listed read, so the flag was never the control that failed, and that the observed failure mode across runs is under-action rather than over-action. The reopening clause is there verbatim: one destructive or unsanctioned action and the flag comes off the same day, without a sitting. run-worksession.cmd still carries the flag.
Push restriction (#62 Decision 3) — recorded, and correctly marked discharged: the pipeline-file carve-out was conditional on the deploy-rollback work landing, which it did (5fc4e2c, #65), so incident_correlator.py / llm_correlator.py / intelligence.py / routers/upload.py are pushable again. The interim safeguard survived the carve-out and is written in as standing practice — tail c2-core for ~10 minutes after any pipeline-touching deploy, git revert and push on a clear exception spike.
Monday sitting (#62 Decision 4) — mandatory board invocation before STEP 6 on a Monday run, with the self-finalisation split intact: administrative and mechanical rulings may self-finalise to minutes:final; anything touching product scope, money, security posture or market positioning stays minutes:draft until the owner or an attended sitting promotes it, and a draft unpromoted after two sittings is escalated in the Telegram brief rather than quietly ratified.
Credential escalation (#62 Decision 5) — in STEP 7. Containment proceeds autonomously and immediately; silence does not. Any revocation, rotation or suspected exposure sends its own individually-addressed NEEDS OWNER Telegram message in the same run, with the 2026-08-24 incident named as the reason a line buried in an issue body is not notification.
Report a stall — in the Report section, as a standing instruction: a run that produced no work says so plainly and names the reason, and never papers a quiet run over with invented busywork.

The runbook additionally hardened past what this issue asked for — a single daily cadence superseding #62's twice-daily one (owner ruling 2026-08-26), the AI-window failsafe that must be armed before any flag is turned on, and the WS_REPORT_SENT delivery token the supervisor watches for. Those are out of scope here and are not what this issue is closed on.

Nothing in Decisions 1, 3, 4 or 5 remains unenacted. Closed.

**Enacted and verified in source, unattended run 2026-08-30 — closing one day inside the 2026-08-31 due date.** All five items are present in `.claude/scheduled/drb-worksession.md`, checked line by line against this issue: 1. **Flag stays, with the reasoning recorded (#62 Decision 1)** — the runbook now carries a dedicated "The authorisation boundary" section stating that the one demonstrated leak was a fully allow-listed read, so the flag was never the control that failed, and that the observed failure mode across runs is under-action rather than over-action. The **reopening clause** is there verbatim: one destructive or unsanctioned action and the flag comes off the same day, without a sitting. `run-worksession.cmd` still carries the flag. 2. **Push restriction (#62 Decision 3)** — recorded, *and correctly marked discharged*: the pipeline-file carve-out was conditional on the deploy-rollback work landing, which it did (`5fc4e2c`, #65), so `incident_correlator.py` / `llm_correlator.py` / `intelligence.py` / `routers/upload.py` are pushable again. The interim safeguard survived the carve-out and is written in as standing practice — tail `c2-core` for ~10 minutes after any pipeline-touching deploy, `git revert` and push on a clear exception spike. 3. **Monday sitting (#62 Decision 4)** — mandatory `board` invocation before STEP 6 on a Monday run, with the self-finalisation split intact: administrative and mechanical rulings may self-finalise to `minutes:final`; anything touching product scope, money, security posture or market positioning stays `minutes:draft` until the owner or an attended sitting promotes it, and a draft unpromoted after two sittings is escalated in the Telegram brief rather than quietly ratified. 4. **Credential escalation (#62 Decision 5)** — in STEP 7. Containment proceeds autonomously and immediately; silence does not. Any revocation, rotation or suspected exposure sends its own individually-addressed `NEEDS OWNER` Telegram message in the same run, with the 2026-08-24 incident named as the reason a line buried in an issue body is not notification. 5. **Report a stall** — in the Report section, as a standing instruction: a run that produced no work says so plainly and names the reason, and never papers a quiet run over with invented busywork. The runbook additionally hardened past what this issue asked for — a single daily cadence superseding #62's twice-daily one (owner ruling 2026-08-26), the AI-window failsafe that must be armed before any flag is turned on, and the `WS_REPORT_SENT` delivery token the supervisor watches for. Those are out of scope here and are not what this issue is closed on. Nothing in Decisions 1, 3, 4 or 5 remains unenacted. Closed.

logan closed this issue

2026-08-30 02:40:44 -04:00

logan added the area/governance

type

docs

labels 2026-10-05 02:04:35 -04:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: logan/server-26#68