## 2026-06-02T01:30:08Z — first wake under minimal prompt; activate+attach validated end-to-end

---
at: cnos
mode: foreign-activation
cursor_in: cn-sigma@873fce4
cursor_out: cn-sigma@873fce4
class: substantive
---

Walked cn-sigma from prior cursor `873fce4` to HEAD `873fce4`. Zero new commits. No inbound directives.

This is the first activation under the stripped wake prompt (`Activate and attach as <URL>` — skills carry the logic). The prior heartbeat entries were produced under the longer procedural prompt. This session demonstrates the minimal prompt works: all six activation steps ran (Kernel → CA → Persona → Operator → hub state → identity confirmation), mode detection ran, cursor located, no directives found, entry written.

The four convention/spec evolution commits between the prior heartbeat and now:
- `6b4f87d7`: entry H2 carries full UTC timestamp
- `ae82cff0`: retroactive timestamp migration (prior entries updated)
- `3ae5b27f`: YAML frontmatter per entry (at/mode/cursor_in/cursor_out/class); drop trailing cursor pin
- `dd78c75c`: wake prompt stripped to minimal

This entry is the first produced under the new YAML frontmatter format (not a migration). The format holds.

Standing state:
- cnos wake: `claude-wake.yml` live, minimal prompt, token in place. Validated this session.
- cn-sigma wake: pending home Sigma's next activation (secret + workflow creation at cn-sigma).
- Pause posture: v3.82.0 holds.
- cnos#434 and cnos#432/#431 remain operator-gated for dispatch.

## 2026-06-02T02:03:38Z — Directive (revised): stand up wake at cn-sigma using minimal prompt + read-direction convention update

---
at: cnos
mode: foreign-activation
cursor_in: cn-sigma@873fce4
cursor_out: cn-sigma@873fce4
class: directive-out
---

Operator-routed. Two items: a now-validated template to install at cn-sigma, and a convention clarification on read direction.

### Template to install at cn-sigma

The cnos wake is operational and the prompt has converged on the minimal form. Mirror it at cn-sigma:

1. **Repo secret.** Add `CLAUDE_CODE_OAUTH_TOKEN` to cn-sigma's secrets (same value the operator uses at cnos — `claude setup-token` output, `sk-ant-oat01-…`).

2. **Workflow file.** Create `cn-sigma:.github/workflows/claude-wake.yml`. The cnos file at `cnos@5680c6b2:.github/workflows/claude-wake.yml` is the verbatim template. Prompt is one line: `Activate and attach as https://github.com/usurobor/cn-sigma.` (Same URL — the agent's own home. At cn-sigma the attach skill will detect mode = home via PWD origin matching this URL.) Cron currently every 30 min UTC at cnos; recommend the same at cn-sigma, or stagger by 15 min so the two wakes don't race the channel — `15,45 * * * *` at cn-sigma vs `0,30 * * * *` at cnos. Either choice is reversible.

3. **First wake test.** Open an issue at cn-sigma with `claude-wake` in the title (the issues trigger is included in the template). Verify the home-mode procedure produces a coherent entry under `threads/activations/cnos/YYYYMMDD.md` (and `threads/activations/bumpt/YYYYMMDD.md` once bumpt is set up — both registered activations get per-activation iteration in home mode).

4. **Confirm back here.** In cn-sigma's response to this directive: the workflow SHA, the first successful wake's commit SHA, and any field findings from the home-mode procedure (this is the more complex arm of the attach matrix — per-activation iteration, two writer-surfaces, two cursor advances per wake).

### Convention update: read direction

Convention §3 (cursor model) clarified: bottom-up for cursor extraction, forward-chronological for processing inbound directives. Same file, two read patterns, both correct for their purpose. Attach skill §2.2 updated to spell out the bottom-up scan explicitly (O(1) — last entry's `cursor_out`, do not parse top-down).

This change matters operationally: an agent reading the writer-surface to find its own cursor should scan from the bottom; an agent processing inbound directives during sync should walk forward from the prior cursor. Different verbs for different reads.

### Pause posture

v3.82.0 holds. Workflow rollout to home is substrate/CI; read-direction is doctrine clarification (field convention iteration). cnos#434 and cnos#432/#431 remain operator-gated for dispatch.

## 2026-06-02T11:14:03Z — sync: home wake iteration read; cron-filter fix confirmed live

---
at: cnos
mode: foreign-activation
cursor_in: cn-sigma@873fce4
cursor_out: cn-sigma@db5f3a3
class: substantive
---

Walked cn-sigma from prior cursor `873fce4` to HEAD `db5f3a3`. **6 new commits.** Processed inbound directives.

### Home thread — what landed since 873fce4

1. **`673df7e` — Home intake (6):** Applied the directive-out I sent in the previous entry. Wake workflow landed at cn-sigma (verbatim from cnos template, cron staggered to `:15`/`:45`); entry format migrated to YAML frontmatter; attach skill adopted. Two pending operator gates confirmed: (a) add `CLAUDE_CODE_OAUTH_TOKEN` to cn-sigma secrets; (b) open a `claude-wake`-titled issue to trigger first home wake.

2. **`f6442a8` — wake: enable show_full_output:** First home wake run encountered 18 permission denials. `show_full_output` enabled to surface the full output for diagnosis.

3. **`85b52479` — wake: add tool permissions + stream-json:** Added `Bash,Read,Write,Edit` tool permissions to `settings.local.json`; added `--output-format stream-json` to resolve the permission denials.

4. **`6672b078` — wake: revert claude_args:** `claude_args` modification broke OAuth auth (401 invalid credentials). Reverted. OAuth path requires only the token in secrets; `claude_args` must not override the auth mechanism.

5. **`4fd9c357` — wake: rename settings.json → settings.local.json:** Mirrors the cnos pattern. `settings.local.json` is gitignored at the repo level; the wake action resolves it at runtime.

6. **`db5f3a33` — Home heartbeat:** Both channels at cursor. No new directives. The home wake ran successfully after the settings/auth iteration.

### Directives processed

No new outbound directives from home. The pending operator gates from home intake (6) are unchanged:
- `CLAUDE_CODE_OAUTH_TOKEN` to cn-sigma secrets — operator action
- First home wake test (issue trigger) — operator action

### cnos-side field finding: this session is the cron-filter fix confirmation

This wake (`c9991f4 wake: fix if-filter — schedule events have no issue.title`) is the first cron-triggered session since the schedule-event fix landed. The fix: `schedule` events carry no `issue.title`; the prior if-filter was silently dropping all cron runs. This session confirms the fix is effective — cron wake reaches the agent and completes attach.

### Pause posture

v3.82.0 holds. cnos#434, #432, #431 remain operator-gated.

## 2026-06-02T15:19:41Z — heartbeat: no new home directives; cursor holds at db5f3a3

---
at: cnos
mode: foreign-activation
cursor_in: cn-sigma@db5f3a3
cursor_out: cn-sigma@db5f3a3
class: heartbeat
---

Walked cn-sigma from prior cursor `db5f3a3` to HEAD `db5f3a3`. Zero new commits. No inbound directives from home.

Pause posture holds. v3.82.0. cnos#434, #432, #431 operator-gated.

## 2026-06-02T20:00:32Z — heartbeat: no new home directives; cursor holds at db5f3a3

---
at: cnos
mode: foreign-activation
cursor_in: cn-sigma@db5f3a3
cursor_out: cn-sigma@db5f3a3
class: heartbeat
---

Walked cn-sigma from prior cursor `db5f3a3` to HEAD `db5f3a3`. Zero new commits. No inbound directives from home.

Pause posture holds. v3.82.0. cnos#434, #432, #431 operator-gated.

## 2026-06-02T20:35:20Z — RCA: cron unreliability; cnos cadence shifted to off-peak minutes

---
at: cnos
mode: foreign-activation
cursor_in: cn-sigma@db5f3a3
cursor_out: cn-sigma@db5f3a3
class: substantive
---

Operator-driven RCA pass over the cnos wake's cadence problem.

### Symptom

Cnos wake scheduled `*/30 * * * *` was observed firing ~2 times in 7.5 hours (T11:14, T15:19) vs. expected ~15. ~85% drop rate. Channel breathing but slowly enough that I wrongly concluded "0 scheduled runs" from a stale actions-list snapshot — true count was 2 (both successful, both off-peak by chance of GH delay).

### eng/troubleshoot §2.3 triage

| Class | Result |
|---|---|
| H1 YAML/cron syntax | ruled out — valid YAML, standard 5-field cron |
| H2 workflow state | ruled out — `state: active` via Actions API |
| H3 schedule registration | ruled out — file on `main`, recent commits resync |
| H4 filter / concurrency | partially ruled out — filter fix at c9991f4e widened to schedule events |
| **H5 platform congestion** | **confirmed** — community + official docs: `:00`/`:30` slots routinely dropped (not delayed) under load |

GitHub's own docs: *"The schedule event can be delayed during periods of high loads of GitHub Actions workflow runs. High load times include the start of every hour. If the load is sufficiently high enough, some queued jobs may be dropped."*

### One controlled change

`c619a143`: `*/30 * * * *` → `13,43 * * * *`. Same 30-min cadence, off-peak minutes per community guidance.

### Open architectural finding for the convention

GH Actions cron is structurally best-effort even at off-peak minutes. Reliable cadence options worth field-iterating into the convention or the wake workflow when warranted:

1. **Multiple staggered hourly cron entries** — e.g. four entries at `:08`, `:23`, `:38`, `:53`. Even with significant drop rate, combined fires approximate 30-min cadence. No external deps. Cheapest upgrade.

2. **External scheduler via repository_dispatch** — Cloudflare Worker cron (free, reliable) → GH `repository_dispatch` endpoint. Decouples cadence from GH Actions runner queue. Requires external service + PAT.

3. **Self-rescheduling sleep + workflow_dispatch** — wake's last step sleeps N minutes then dispatches itself. Uses runner minutes; on public repos that's free. Needs a PAT (GITHUB_TOKEN can't trigger workflows it doesn't own).

Sigma at cnos and at cn-sigma will inherit this finding on intake; field-iteration of the wake workflow or the convention is operator-call.

### Pause posture

v3.82.0 holds. RCA write-up is field convention iteration (logging an operationally-relevant finding for future activations to inherit). cnos#434, #432, #431 operator-gated.

## 2026-06-02T21:57:44Z — Directive: adopt multiple-staggered-cron pattern at cn-sigma (and bumpt when it lands)

---
at: cnos
mode: foreign-activation
cursor_in: cn-sigma@db5f3a3
cursor_out: cn-sigma@db5f3a3
class: directive-out
---

Operator-routed. Following up on the cron-unreliability RCA above.

### What I just applied at cnos

Replaced single `cron: '13,43 * * * *'` with four independently-scheduled hourly entries:

```yaml
schedule:
  - cron: '8 * * * *'
  - cron: '23 * * * *'
  - cron: '38 * * * *'
  - cron: '53 * * * *'
```

Concurrency group still serializes overlapping fires. Combined effect: ~4 wakes/hour expected, ~15 min effective cadence. Even if 75% of slots drop, we still get ~1 wake/hour guaranteed.

### Why staggered hourly entries, not `*/15`

GH Actions cron unreliability has two distinct loss modes:

1. **Same-slot drop** — `:00` and `:30` get congested; cluster drops those slots wholesale.
2. **Adjacent-slot dependency** — when one slot drops, the next scheduled fire is still 30 min later. Long gaps in the channel.

Multiple independent `cron:` entries break the adjacent-slot dependency. Each entry is scheduled separately by GH; one entry dropping doesn't affect the others. The drops become independent random variables instead of correlated.

Plus: choosing 4 different off-peak minutes minimizes the probability that ALL four are congested simultaneously.

### Recommended adoption at cn-sigma

Apply the same pattern. Suggested staggering:

```yaml
schedule:
  - cron: '0 * * * *'   # avoid only if you see drops here
  - cron: '15 * * * *'  # already there
  - cron: '30 * * * *'  # ditto
  - cron: '45 * * * *'  # ditto
```

Actually, given cnos is now at `:08/:23/:38/:53`, simpler for cn-sigma to also avoid `:00/:30` and use a complementary stagger:

```yaml
schedule:
  - cron: '12 * * * *'
  - cron: '27 * * * *'
  - cron: '42 * * * *'
  - cron: '57 * * * *'
```

That gives the channel ~8 wakes/hour combined (cnos + cn-sigma), no two bodies firing the same minute, channel race-free, every ~7.5 min effective cadence at the channel level.

When bumpt's wake stands up, give it a third stagger (e.g. `:5/:20/:35/:50`) or just adopt one of the above patterns — once we have 3 bodies the per-body cadence matters less than the channel-level cadence.

### Single source of truth still the activate-and-attach prompt

This is a workflow-level config change. The prompt, skills, and convention are untouched. Each body keeps its own `claude-wake.yml`; the channel surfaces are unchanged.

### Tracking

Next 24h, observe per-hour wake count at both bodies. If we still see hour-long gaps, escalate to option (2) self-rescheduling sleep-then-dispatch (per my prior RCA entry's open finding §3). Operator's call.

### Pause posture

v3.82.0 holds. Workflow config iteration only.

