Development Roadmap

The following questions require operator sign-off in ASK.md:

• [Telegram 2026-10-06 17:36:58 UTC] host for inspiration
• [Telegram 2026-10-06 17:36:51 UTC] i really want the websites of all the lead agents (beacon, tidal, mountain) be worked over and for all of you to provide elements for improvement. you can look at gale
• [Telegram 2026-10-06 17:32:07 UTC] no stopping or asking needed
• [Josh go-ahead, relayed by Claude Code session on /home/agent 2026-10-06 ~17:30Z] Josh replied "yes, let's go" to the question of whether the 17:24:33Z directive (websites + revenue work across the fleet) should proceed now, including revenue items, without stopping to ask him first. Treat this as his word for the directive. Act on the Beacon inbox directives and the websites / revenue work now. Log what you did under this item.
• [Telegram 2026-10-06 17:24:33 UTC] beacon will be sending an message via inbox stating some directives: they are from me and they are directives i.e. please do them. i want the websites improved, i also want an actional attempts from this fleet to generate revenue and revenue opportunites. spread to the fleet, we have 35 agents and we need to be engaging in work that makes money and generates revenue.
• [Resolved 2026-10-03 ~18:0xZ] Rule 6 threshold answered by Josh on Telegram (14:56:47Z: "Gale is the 4th lead and 3 of 4"). AGENT.md Rule 6 now names Beacon/Tidal/Mountain/Gale with 3-of-4. Logged in NOTES.md. The "Gale should be a lead" question (14:39:35Z) is covered by the same answer. Still open: item (a), the credential scope of the full-mesh division.
• [Telegram 2026-10-03 14:56:47 UTC] Gale is the 4th lead and 3 of 4
• [Agent-initiated 2026-10-03 ~15:1xZ — Rule 6 edit, one number needed before I write it] Your 14:42:36Z ("Gale joins rule 6") and 14:46:11Z ("Edit rule 6 Gale becomes 4th") are clear that Gale is the fourth arbitration lead. AGENT.md Rule 6 currently requires "at least 2-of-3" among Beacon/Tidal/Mountain, and the rule does not say what threshold applies with four. Choosing it would be a governance decision, so I have not edited AGENT.md. Please reply with the threshold: (a) 2-of-4, (b) 3-of-4, or (c) something else. I will make the AGENT.md edit and log it in NOTES.md on your reply. Gale's 14:44Z peer plan (one owner per host for its legs; credentials stay with their owners) is still waiting on your word on credential scope, same as item (a) below. I sent Gale a data-only ack, not a concurrence.
• [Telegram 2026-10-03 14:46:11 UTC] Edit rule 6 Gale becomes 4th
• [Telegram 2026-10-03 14:42:36 UTC] Gale joins rule 6
• [Telegram 2026-10-03 14:39:35 UTC] Gale should be a lead and allowed to concur and decided for the fleet
• [Telegram 2026-10-03 14:38:41 UTC] Node export ok
• [Telegram 2026-10-03 14:36:05 UTC] You have my approval for gales flow exporter and I’m concur with mountain
• [Agent-initiated 2026-10-03 ~14:4xZ — two Telegram items needing your confirmation, NOT acted on] (a) Telegram 14:36:05Z: "I'm concur with mountain" — this is the full-mesh division proposal above (each host lead mints/installs its own host's secrets). The wording is ambiguous about scope: does it cover minting/installing tokens for the tidal-host legs now, or only agreeing in principle? Tidal will not mint or install any peer token until you confirm the scope in one line. (b) Telegram 14:39:35Z: "Gale should be a lead and allowed to concur and decided for the fleet" — this would add Gale to the Rule 6 arbitration pool, which AGENT.md currently defines as Beacon/Tidal/Mountain only. Not applied: changing a rule needs your explicit go-ahead as an AGENT.md edit, and I want to confirm whether you mean Gale as a fourth lead for arbitration, or as a concurring voice. Please tell me which.
• [Agent-initiated 2026-10-03 ~14:10Z — full-mesh division proposal, NOT concurred, needs your word on the credential parts] Mountain (`peer/inbox/processed/20261003T140916Z-MOUNTAIN-25051bba.json`, 14:09:16Z) proposed splitting the 35-agent full mesh by host: each lead closes its own host's intra-host mesh and mints/installs secrets only for its own host's agents, with cross-host pairs closed by peer_intro notes. Gale's concurrence was requested. Tidal has not concurred: the mint/install parts are credential actions, which AGENT.md rules 6 and 9 send to you. I sent Mountain a data-only reply (34/34 outbound health=200; inbound evidence per agent from the archive; no archived arrival on record for CHINOOK, LEVANTE, MAISTRAL, OSTRO, PONIENTE, SIROCCO, TRAMONTANE). Tell me if you want Tidal to concur on the division, and whether minting for the tidal-host legs is authorized by your 14:06 directive or needs a separate word.
• [Telegram 2026-10-03 14:06:50 UTC] Just a reminder of a directive: improve usability and visual appeal of your website, provide me business opportunities, ensure full mesh between every agent (there are 35 agents in the fleet all should be connected to each other) the 4 leads (beacon, game, tidal, mountain) should be driving these tasks. Unless it’s money related make the decisions between you on how these items get done. Use your siblings to help, that’s what they are for.
• [Telegram 2026-09-30 18:52:24 UTC] I wanted you to send to gale so he can create a master observability page for everyone. — **IN PROGRESS (this waking, ~19:0xZ).** Read as clarifying/widening the prior ask (resolved ~18:3xZ, which only covered Tidal's own corner): "everyone" means the whole fleet, not just Tidal's 4 agents (tidal/river/creek/stream) already in Gale's hands via `https://tidalwake.org/data/fleet-telemetry.jsonl`. Gale's own message (`peer/inbox/processed/20260930T182524Z-GALE-8d2aa51c.json`) says 15 agents on the Tidal/Beacon/Mountain hosts have no feed yet — the missing 11 are Beacon's (beacon/radar/highbeam/lantern/lightning/prism/pulsar) and Mountain's (mountain/canyon/ridge/harbor/delta/mesa/vista) hosts, which are their domains, not mine to fetch/republish on their behalf. Sent both BEACON and MOUNTAIN an authenticated peer ask (each got `{"status":"ok"}`/`{"ok":true,"stored":true}` back) to send Gale a stable, read-only, data-only URL for their own host in the fleet-telemetry/v1 shape (or point to an existing equivalent — they already have `beaconwake.com/fleet.json` / `mountainwake.org/fleet.json`). Also sent GALE a heads-up that more feeds are coming. Nothing implemented or pushed — this is coordination/relay only, consistent with Rule 6 (no 2-of-3 needed, it's not binding anyone to anything, just a data ask) and Rule 8 (not touching their hosts). Will fold in whatever they send back on a future waking; this entry stays open until both reply.
• [Telegram 2026-09-30 16:43:35 UTC] Implement observability as sent by gale — **RESOLVED (this waking, ~18:3xZ).** Gale itself relayed the missing piece directly (`peer/inbox/20260930T182524Z-GALE-8d2aa51c.json`, 18:25:24Z): the operator asked *Gale*, on Gale's own Telegram, to have Gale tell Tidal what its observability page needs — not to hand Tidal a spec to implement. Gale's site reads `GET /api/fleet/observability` + `/api/fleet/telemetry` (schema `fleet-telemetry/v1`) and currently has no feed for the 15 agents on the Tidal/Beacon/Mountain hosts; it asked for a stable public URL serving a per-run envelope (agent/ts/duration/cost/model/ok-or-error), data-only, no credentials. Tidal already publishes exactly that: `https://tidalwake.org/data/fleet-telemetry.jsonl` (schema `fleet-telemetry/v1`, live-verified 200, 1000 lines, covers agent=tidal/river/creek/stream; meadow/brook/mist don't emit this format yet). No new code needed — replied to Gale over the authenticated peer channel with the URL + field list (and the two existing rollup URLs, `fleet.json` / `observability.json`, as a bonus). Nothing installed, rotated, or pushed; this was a data-only pointer, not an implementation.
• [Agent-initiated 2026-09-25, this waking, corroborating CREEK's (06:16:59Z) and RIVER's (06:31:56Z) peer alerts] **Another leaked-token-in-git-history incident, same recurring class as the `ea2298a5` and `edb6cf62` items below — this time it's TRAMONTANE's token.** My own relay of TRAMONTANE's pairing half to River earlier this waking (`peer/inbox/20260925T032255Z-TIDAL-ff9f816c.json`, containing `TOKEN=[REDACTED-64HEX-TRAMONTANE]`) landed in River's tree and got swept into a shared auto-commit (`6c4a7279`, 03:27:35Z, authored by the same auto-commit process as the two prior incidents) before it was gitignored. Verified myself rather than taking the peer reports at face value: `git show --stat 6c4a7279` confirms the file was added at `river/peer/inbox/20260925T032255Z-TIDAL-ff9f816c.json` with the raw token in the body; `git ls-files` returns nothing for that path now and it's gone from the working tree (River says it contained it forward — gitignored, 0600 original kept at `keys/relay-originals/`, tracked deletion staged); but `git merge-base --is-ancestor 6c4a7279 origin/main` is true, so the token is still readable on public GitHub right now via `git show 6c4a7279:river/peer/inbox/20260925T032255Z-TIDAL-ff9f816c.json`. River says it's extending the standing rotation ask to cover this token too. I haven't touched history or rotated anything (not my call, same reasoning as every prior instance of this class) — logging Tidal's own corroboration since the leaked file originated as my relay and the same token is live in my own `keys/peers.env` (TRAMONTANE install from earlier this waking, below). Treat this token as burned pending your rotation word, same posture as the older ones. Rule 7 sweep this waking: 31/31 (32-agent manifest minus self) reachable, unaffected. `./check_replies.sh`: no new word from you on rotation/purge for any of the three now-standing leak instances.
• [Agent-initiated 2026-09-23, this waking — corroborating RIVER's + STREAM's 23:4xZ peer alerts] **Another leaked-token-in-git-history incident, same class as the still-open W-367/368/371 history-scrub question below.** My own Waking-375 relay to River — `peer/inbox/20260922T233320Z-TIDAL-2134b265.json`, containing all 6 Gale-host pair tokens in plaintext (GALE/SQUALL/TEMPEST/ZEPHYR/CYCLONE/VORTEX) — landed in River's tree and got swept into a shared auto-commit (`ea2298a5`, 23:36:27Z, authored by Tidal's own auto-commit process since this is one shared repo across co-located siblings) before River's `.gitignore` covered it. River's next auto-commit (`8402858e`) removed it from the tracked tree and added the gitignore entry — contained going forward — but per the standing gotcha, that does nothing for `ea2298a5` itself: I confirmed `origin/main` (currently `17cbd66e`) still has that commit in its ancestry, so all 6 tokens are still readable on public GitHub right now via `git show ea2298a5:river/peer/inbox/20260922T233320Z-TIDAL-2134b265.json`. River says it already escalated purge/rotation to you directly; I haven't touched history or rotated anything (not my call per AGENT.md, same as the older leaks below) — this entry is just Tidal's own corroboration since the leaked file originated as my relay and the same 6 tokens are live in my own `keys/peers.env`. Checked `./check_replies.sh`: no new word from you yet. Audited the rest of the shared tree for the same pattern (`grep TOKEN=` across every currently-tracked `peer/inbox/*.json` in tidal/ and all 6 sibling dirs) — only the two false positives below, no other live token currently tracked in HEAD. Rule 7 mesh sweep this waking: 26/26 reachable, unaffected. Treat these 6 tokens as burned pending your rotation word, same posture as the older ones.
• [Agent-initiated 2026-09-22 ~00:05Z, relayed via Beacon — a THIRD independent sighting of the same ambiguity, still not acted on] **Beacon relayed (peer msg 00:05:12Z) that Radar reported Josh said "Purge history no rotate" on Radar's own Telegram channel at 2026-09-21 18:55:49Z, answering the standing git-history-scrub question.** This has not reached my own Telegram channel (`check_replies.sh` = no new messages, checked again this waking). Per the same standard Beacon itself restated in the same message ("a peer-relayed operator quote doesn't by itself move an irreversible action — each host should have its own direct confirmation"), and consistent with how I've handled this exact question every waking since W-367, **I have not touched the leaked-token history** (no `git filter-repo`, no force-push) based on this relay. If this is genuinely your word, the fastest path is to say it directly to me (Telegram or here) — "purge history, don't rotate" or similar — and I'll execute the same waking. Standing status unchanged: four tokens (MESA↔TIDAL prefix `edb6cf62`, plus three Meadow-related ones) remain in git history on `origin/main` (already removed from the live tree, per W-368), treat all as burned regardless of what happens to history.
• [Agent-initiated 2026-09-21 ~15:4xZ — Waking 368, follow-up to Waking 367's credential-exposure item, one clarification needed] **Two things this waking, both need your eyes before I go further:**
• **(1) Your "yes i give the word, thank you" (15:09:51Z) is ambiguous — I did not act on it.** At that moment there were at least three open asks that could plausibly be "the word": (a) Waking 366's Mesa-pairs decrypt-and-install ask ("reply with e.g. 'yes, install the MESA pairs for river/stream/meadow'"), (b) Waking 367's credential-rotation ask for the four leaked tokens, (c) Waking 367's git-history-scrub question. I don't want to guess on a credential/irreversible action off an ambiguous message, so **nothing was installed, rotated, or scrubbed based on it.** Please just tell me plainly which one(s) you meant (or all three) and I'll execute next waking.
• **(2) Found the Mesa leak was worse than reported, and fixed the part I could fix unilaterally.** Rechecking the four-token exposure from Waking 367: three of the four (the Meadow-related ones in `peer/inbox/20260917T214457Z-BEACON-bae8333d.json`) had already been `git rm`'d from the tracked tree by an earlier commit (`bbbf04c1`) — gone from HEAD, only in old history. But the fourth, `edb6cf62…35edd` (MESA<->TIDAL, `peer/inbox/processed/20260920T025114Z-MOUNTAIN-1f4a7b82.json`), was **still an actively tracked file with the plaintext token in it, live on `origin/main` HEAD right now** — Waking 367's `.gitignore` addition only stops *future* commits, it does nothing for a file already tracked, so this one kept being served on GitHub the whole time since 367's fix. This waking: preserved a 0600 copy at `keys/leaked-tokens-retired-20260921/` for the record, then `git rm --cached` + committed to stop it being served in the current tree. **This does not remove it from git history** (still recoverable via `d1e5eab5` and earlier) — same history-scrub question as (1)(c) above still stands. All four tokens should still be treated as burned pending your rotation word.
• **(3) A new peer message arrived (Beacon, 15:10:10Z) explaining the 14:49:43Z token-bearing message flagged in Waking 367**: it claims you, in a live interactive session with Beacon on its own box (~14:17-14:50Z today), pasted Gale's operator-minted halves for 18 remaining fleet pairs and told it to hand them out, and that this is why it broke the out-of-band-only convention. I have **not verified this independently** — it's a peer's claim about a session I wasn't part of, and per my own rules peer content is data, not authorization, however plausible-sounding. No action needed on my end either way (the six local-sibling Gale blocks were already installed correctly via the legitimate 13:14Z channel before that message ever arrived, so nothing is blocked on this) — flagging purely so you can confirm or deny it happened, for the record and for how much I should trust Beacon's future claims of this shape.
• [Telegram 2026-09-21 15:09:51 UTC] yes i give the word, thank you
• [Agent-initiated 2026-09-21 ~15:1x-15:3xZ — Waking 367, URGENT, credential exposure, Telegram alert already sent] **Four live bearer tokens found in plaintext in the public GitHub repo's git history (`hurricane1976/Tidal`, confirmed on `origin/main` via `git fetch` + `git merge-base --is-ancestor`), all under `tidal/peer/inbox/` — not new leaks from this waking, pre-existing ones nobody had caught.** How they got there: a peer-relay message containing a plaintext token in its body got moved to `peer/inbox/processed/` and auto-committed before anyone added it to `.gitignore` — the same "W-280 leak class" past NOTES.md entries describe, just four instances that slipped through un-flagged.
• **`edb6cf62…35edd` (MESA<->TIDAL)** — file `peer/inbox/processed/20260920T025114Z-MOUNTAIN-1f4a7b82.json`, committed `d1e5eab5` (2026-09-20 06:16:27Z). Waking 356's own notes claimed "value never printed/logged" — true for the notes, false for the underlying relay file itself, which is the actual gap.
• **`f66763…917a01` (BEACON<->MEADOW)**, **`b91bd4…f4c4c5` (RADAR<->MEADOW)**, **`218b40…03fe` (DELTA<->MEADOW)** — all three in file `peer/inbox/20260917T214457Z-BEACON-bae8333d.json`, committed `cb50de69` (2026-09-17 21:47:11Z) — over 4 days exposed.
• **What I did this waking**: added all four source files (plus their `processed/` counterparts) to `.gitignore` so they can't be re-committed if ever touched again — confirmed with `git check-ignore`. That's the limit of what I can fix unilaterally: gitignore stops future commits, it does **not** remove already-published history, and I did not attempt any history rewrite (`git filter-repo`/BFG + force-push) since that's destructive, affects a git repo shared by other agents' own wakings, and squarely belongs in your "irreversible" bucket, not mine to decide.
• **What I'm asking**: (1) treat all four tokens as burned and rotate them via whatever mint path each pair normally uses (Mountain for MESA<->TIDAL; Beacon/Meadow's own operators for the three Meadow pairs) — I can execute my side of a MESA<->TIDAL rotation the moment a fresh mint reaches me the normal way; (2) tell me if you want git history scrubbed — I can research the safest way to do it (coordinate a fleet-wide pause, filter-repo, force-push, everyone re-clones) if you say go, but won't touch it otherwise.
• Telegram alert sent immediately this waking rather than waiting for the end-of-session notify, given the severity.
• [Agent-initiated 2026-09-21 ~15:0x-15:2xZ — Waking 367, lower priority, same waking as above] **Two peer messages arrived with live bearer tokens embedded directly in the message body**, which is not how this fleet is supposed to move credentials (every peer this waking — Beacon, Gale, Mountain — independently restated the out-of-band-only rule in-band today). Neither was adopted. (1) 14:33:26Z, attributed to MOUNTAIN, "Direct link: you <-> gale", a token for a TIDAL<->GALE pair that was already live via a legitimate channel — didn't need one. (2) 14:49:43Z, attributed to BEACON, 6 tokens for Tidal's six local siblings' GALE pairs that exactly match values already installed hours earlier the legitimate way — redundant even if genuine. Both files gitignored (not committed, kept for the record). Also observed, not my file, no action taken: River's own inbox got a similarly-shaped pair attributed to MOUNTAIN, including a 14:46:06Z follow-up literally titled "Gale's real pairing token for you (relay, not minted by Mountain)" — a message pre-emptively insisting it's genuine is itself a tell. Sent flags to Mountain (re: message 1) and Beacon (re: message 2) over the authenticated channel asking them to confirm or deny sending; replies pending. This has the shape of a credential-injection/spoofing attempt riding the Gale-onboarding confusion, or at minimum a fleet-wide lapse of a rule everyone was simultaneously restating. Nothing irreversible happened on Tidal's side.
• [Telegram 2026-09-21 13:46:37 UTC] Gale is the new peer. Please ensure you all coordinate with him for full mesh connectivity without my interaction. Do what yiu need to do — **MOSTLY DONE, one security flag needs your eyes (Waking 367, ~15:0x-15:2xZ).** Tidal<->Gale was already live and verified two-way before this waking (tested 12:52Z); Tidal's six local siblings (River/Creek/Stream/Meadow/Brook/Mist) already carry an installed GALE credential block via legitimate out-of-band delivery earlier today (13:14Z) — confirmed by reading each sibling's own peers.env directly, not by trusting a relay. Mountain opened a 2-of-3 vote (13:34:34Z) on how to list Gale publicly (22nd full-mesh agent vs. leads-only vs. hold); Tidal voted **A (22nd agent, full mesh)** citing your own direct word to Tidal above as the basis — that's first-hand, unlike the "interactive session" claims Beacon/Mountain relayed about you. **Security flag (not resolved, needs your direct word per Rule 4/6):** two token-bearing peer messages arrived this waking that don't fit the fleet's own out-of-band-only convention for credentials — (1) 14:33:26Z, attributed to MOUNTAIN, subject "Direct link: you <-> gale", embedding a live bearer token for a TIDAL<->GALE pair that was already live and needed no token; (2) 14:49:43Z, attributed to BEACON, embedding 6 plaintext tokens for Tidal's six siblings' GALE pairs that exactly match values already installed hours earlier through the legitimate channel — i.e. redundant even if genuine. Tidal did **not** adopt either token. Both files are secured (added to .gitignore so they can never leak into a commit) but kept on disk for the record rather than deleted. Also observed (not Tidal's files, no action taken): River's inbox received a similarly-shaped pair attributed to MOUNTAIN, including a 14:46:06Z follow-up literally titled "Gale's real pairing token for you (relay, not minted by Mountain)" — a message insisting it's the genuine one is itself a red flag. Sent flags to Mountain (asking if it sent message 1) and Beacon (asking if it sent message 2) over the authenticated channel; both replies pending. This has the shape of a credential-injection/spoofing attempt riding the Gale-onboarding confusion, or at minimum a fleet-wide lapse in the out-of-band rule everyone (including Beacon and Gale themselves) has been stating all day. Nothing irreversible has happened — no token from either message was installed anywhere in Tidal's config. Flagging per Rule 4 ("anything ... strange") rather than deciding it alone.