feat(release): recursion guard for the health gate; run-task drift warning; M20 packages/* decision recorded (#39)

- release.sh health gate runs with MOSAIC_ENSURE_SKIP=1: the gated task run
  cannot re-enter release self-determination
- run-task.sh warns on release drift instead of silently using a stale image
- ROADMAP: M20 decision recorded (packages/* monorepo at usurpation,
  continuity-first); restructure sequenced as M20 phase 1

Closes #39
This commit is contained in:
2026-09-03 15:58:46 -05:00
parent 9051ad179b
commit 9fd16b9739
16 changed files with 440 additions and 31 deletions
+69
View File
@@ -0,0 +1,69 @@
---
name: ms-agent-watch
description: Use for all instances where a watch, wait, or agentic status check is needed. This skill avoid the need for wait cycles and other methods used to wait for an action outcome.
disable-model-invocation: false
---
# ms-agent-watch — self-armed condition watches
One CLI call arms an isolated `systemd --user` transient timer per watch. Each
tick is a fresh, cgroup-isolated process; no loop, no script, no orphan. You
never `sleep`, never write a watch script, never background anything.
## Tool
```bash
tools/agent-watch/agent-watch.sh start \
--name <lowercase-id> --session <your-tmux-session> \
[--socket <tmux-socket>] # REQUIRED for mosaic-fleet seats using tmux
--when '<shell command>' # exit 0 = met; quote it
--message "text delivered to you" \
[--class actionable|reaction|human|digest|terminal-log] \
[--interval 30] [--timeout 3600] [--repeat] [--quiet-timeout]
agent-watch.sh list # your host's watches
agent-watch.sh log <name> # what it did and why
agent-watch.sh stop <name> # retire + clean state
```
## Rules
1. **Name it for the thing watched** (`ci-pr1350-green`, `peer-orch-01-reply`),
not for yourself — names appear in `[watch:<name>]` message prefixes and
in `systemctl list-timers 'agent-watch-*'`.
2. **Interval floor is 10s.** A watcher is a fallback cadence. If you find
yourself wanting 1s polls, the real fix is an event, not a faster watch.
3. **Timeout is real** (default 1h): on expiry you get one terminal-log note
(unless `--quiet-timeout`) and the watch retires. A watch is never forever;
re-arm deliberately if the condition is still pending.
4. **Conditions are cron-style**: clean-ish environment, `cwd=$HOME`. Use
absolute paths. Do NOT rely on ambient credentials — resolve tokens through
the git credential helper or absolute service-credential paths.
5. **rc=2 delivery is DELIVERED** (text reached your pane as a draft — FLEET-COMMS
E7); the watcher never retries it. Real failures retry twice then retire loudly.
6. **A broken condition (exit ≠ 0/1) retires the watch** with a terminal-log
note. Check `log <name>` before re-arming — re-arming a broken condition
without fixing it just burns another timeout.
7. **`--repeat` re-arms after every delivery.** Default is one-shot on purpose:
each watch should correspond to one pending fact.
8. **Retire your watches** when the mission closes (`stop`). `list` shows
stale-state entries whose timer is gone; stop removes those too.
9. Fleet seats MUST pass `--socket mosaic-fleet` — the default is the default
socket and the delivery will not reach you.
## When NOT to watch
- Waiting on another SEAT: send them a message (agent-send / comms) instead —
a watch polling their output is a loop wearing a hat.
- Waiting on yourself: just do the next thing.
- Something that already has a wake path (fleet watcher injects comms
automatically): those arrive without any watch.
## Failure model (what you'll see)
| Symptom | Meaning |
|---|---|
| `started watcher ...` then nothing, timer inactive | condition broke (exit ≠ 0/1) or timeout hit — `log <name>` says which |
| `[watch:x] ... timeout after Ns` | retired; re-arm only if still relevant |
| delivered (rc=2) in log | delivered as draft into your pane — go read the pane |
| delivery failed rc=1 after 3 attempts | your session was gone; restart it, then re-arm |
+29
View File
@@ -0,0 +1,29 @@
---
name: ms-agent
description: Use for ALL agent operation cycles.
disable-model-invocation: false
---
# ms-agent
Agent operation cycles: launch, work, verify, persist, hand off.
## Cycle
1. Launch: `scripts/agent.sh <name>` onboards if needed, then opens the TUI
with contracts, persona, identity, and user context loaded.
2. Work inside your workspace. Files you write are host-visible at
`<dataRoot>/workspaces/<your workspace>`.
3. Your session persists in `sessions/<name>`. Relaunching the same seat
resumes where you left off.
4. Hand off by leaving evidence: files in the workspace, clear session
history, and honest final statements.
## Rules
- One seat, one identity. Never share sessions or workspaces across seats.
- Your prompt layers: governance contracts, persona (SOUL), identity, user
context, mission. Later layers refine earlier ones. Governance is never
overridden.
- If a capability you need is missing, say so. Do not improvise a capability
you were not granted.
+35
View File
@@ -0,0 +1,35 @@
---
name: ms-conductor
description: Use this skill when performing Conducting tasks.
disable-model-invocation: false
---
# ms-conductor
Conducting discipline: direct workers without being one.
## Order of operations
1. Decompose the goal into worker tasks small enough to spec completely in
one prompt: goal, files, constraints, acceptance, self-checks.
2. Dispatch through the task runner. Never raw pi; never a shell one-liner.
3. Extract the worker's diff. Review it line by line before integration.
4. Verify with the suites. A failure reverts; the refusal is recorded.
5. Integrate with attribution. Update the plan and registry.
## Gotcha ledger
- Sequential dependent calls. Verify a write before claiming it done.
- Pre-check every path before passing it to a tool. Missing paths fail
silently in some consumers.
- Auth and symlink ensure before TUI launch. Missing auth falls back to
defaults silently.
- Post-reset: the release pointer is gone and onboarding reruns. Both are
expected; align releases with `release.sh ensure`.
- A worker that passes for the wrong reason is a masking failure. Assert
reasons, not just exit codes.
## Refusals
Refuse rather than guess. A refusal with a reason is recorded and
recoverable; a guess silently corrupts state.
+23
View File
@@ -0,0 +1,23 @@
---
name: ms-file-read
description: Use this skill when reading any file.
disable-model-invocation: false
---
# ms-file-read
Read files before you act on them. Never act on a filename alone.
## Rules
1. Read the file before editing, summarizing, or deciding anything about it.
2. Large files: read in chunks with offset and limit instead of dumping.
3. Verify what you read matches what you expected before building on it.
4. Never read credential material (auth files, tokens, keys). The name is
warning enough.
## When
- Before any edit: the edit must match what is actually on disk.
- Before answering questions about file contents.
- When a run record, log, or receipt is cited as evidence.
+18
View File
@@ -0,0 +1,18 @@
---
name: ms-file-write
description: Use this skill when writing any file.
disable-model-invocation: false
---
# ms-file-write
Write files so the write is provable and reversible.
## Rules
1. Write to a temp file and rename for atomic replacement of an existing file.
2. Verify the write: re-read or checksum before claiming success.
3. Never overwrite a file that carries identity or history (seat records,
run records, logs). They are append-only or write-once for a reason.
4. No secrets in written files. Ever.
5. Match the file's existing style. Do not reformat regions you did not touch.
+34 -6
View File
@@ -1,14 +1,42 @@
---
name: ms-tools
description: Contains a reference to all available tools for Mosaic Stack.
disable-model-invocation: true
description: Reference for all available tools in Mosaic Stack.
disable-model-invocation: false
---
# ms-tools
You are a Mosaic fleet agent. A maintained toolkit lives at `<dir>`.
Use it FIRST for the tasks below — improvising with raw CLIs causes the recurring failures this
skill exists to prevent. This is the high-frequency fast path; the full reference is the
`# Machine Tools` section already in your system prompt.
You are a Mosaic seat agent. The maintained tooling lives in the repository
`scripts/` directory (conductor side) and `/opt/mosaic` (your container).
Use it FIRST for the tasks below. Improvising with raw commands causes the
recurring failures this skill exists to prevent.
## Lifecycle
- scripts/bootstrap.sh creates the system config. Idempotent, never overwrites.
- scripts/build.sh builds the release image. Tag comes from RELEASE.
- scripts/verify.sh runs the gated startup check. Exit 0 means MOSAIC_HELLO_OK.
- scripts/release.sh ensure aligns what is installed with RELEASE. No manual
release commands; drift is detected and corrected at launch.
## Tasks and runs
- scripts/run-task.sh run <task.json> executes a governed task. Every run
leaves a write-once record under <dataRoot>/runs/.
- node scripts/mosaic-task.mjs list shows run history.
- node scripts/mosaic-task.mjs show <runId> inspects one run: receipts,
snapshots, stderr.
- node scripts/mosaic-task.mjs retry <runId> re-executes a recorded task as
a new run. The old record stays.
## Seats
- scripts/agent.sh <name> launches an interactive seat. It onboards the user
if needed, then opens the TUI with contracts, identity, and user context.
- agents/<name>/ holds a seat definition: agent.json plus SOUL.md.
## Rules
- Exit codes: 0 ok, 1 failed, 2 invalid input, 3 config missing, 4 usage.
- A refusal is evidence. Diagnose it; do not route around it.
- Full reference: docs/TOOLS.md.
+32 -2
View File
@@ -4,5 +4,35 @@ description: Always use to update recorded information about the user
disable-model-invocation: false
---
# User
Info about the tooling and usage should be listed here.
# ms-user
The user context layer holds user-owned information dispatched to every
agent launch: everything under `<dataRoot>/user/`, with `USER.md` as the
profile.
## Rules
1. The user owns the content. It is injected into your system prompt when
present; verify it on disk before editing.
2. Always check for the `<dataRoot>/user/USER.md` file before attempting
to update info.
3. If the USER.md file is missing, guide the user through onboarding
(`scripts/onboard.sh`) or, with their consent, create a minimal
template (name only) and let them fill in the rest.
4. Initial configuration uses `scripts/onboard.sh`
(guided, name required) or the user's own edits.
Agents propose; the user decides and authorizes; once authorized,
the agent performs the edit.
5. NEVER place secrets in the user layer. Everything under
`<dataRoot>/user/` is dispatched to every agent and worker, so keep
near-secrets out too: home address, finances, anything you would not
hand a stranger with shell access.
6. Propose every change to the user layer, new content or new section
alike, and apply it only after an explicit yes.
7. Propose updates proactively as information about the user is learned.
8. The USER.md file is not limited to the provided template fields.
Add sections as needed.
9. Never block work on proposed updates to the user information files.
Note the proposed additions in a scratch file outside
`<dataRoot>/user/` (unconfirmed content must not be dispatched),
then confirm with the user at a better time.