mosaicstack/stack
1
0
Fork 0
Code Issues 77 Pull Requests Actions Packages Projects Releases 15 Wiki Activity

docs(framework): augment mosaic-orchestrator Worker Launch Rules with WHY + pi/gpt yolo model syntax #823

New Issue
Open
opened 2026-07-17 21:23:01 +00:00 by jason.woltje · 1 comment
jason.woltje commented 2026-07-17 21:23:01 +00:00
Owner
Copy Link

Summary

Augment the mosaic-orchestrator skill → "Worker Launch Rules (MANDATORY)" so the #1 launch rule is unambiguous. Today it says "Always use mosaic yolo <agent> from the project directory" but omits (a) the WHY and (b) the GPT/pi model syntax. That thinness was the direct root cause of a real incident (2026-07-17): a worker (ms-792) mis-launched without mosaic yolo sat on permission dialogs, requiring hand-approval, until relaunched under yolo.

Requested by Jason (owner, #mos 2026-07-17 21:15Z) via Mos. Small framework-doc change. Queued behind the MS-LEAD ≤2 goal cap — does NOT preempt #792/#818 or gitwatch; does NOT consume a goal lane.

Why this matters

~/.config/mosaic is NOT a git repo — in-place edits to the installed skill get wiped on upgrade (framework-v3 already proved this). The augmentation must land in the framework SOURCE via a reviewed PR so it survives upgrades.

Change to make

In the mosaic-orchestrator skill's "Worker Launch Rules (MANDATORY)" section, make the launch rule prominent (it is the #1 rule) and add:

WHY: mosaic yolo launches the runtime in dangerous-permissions (bypass) mode. A correctly-launched worker NEVER hits a permission dialog. A worker stuck on a permission prompt = a launch-protocol violation → relaunch via mosaic yolo, do NOT hand-approve the dialog.

MODEL SYNTAX (explicit):

  • Codex / pi: mosaic yolo pi --model openai-codex/gpt-5.6-{sol,terra}:{high,medium}
  • Claude: mosaic yolo claude
  • (existing) mosaic yolo codex, mosaic yolo glm

Placement / gates

Land in the framework SOURCE under packages/mosaic (skill/guide source; candidate areas: packages/mosaic/src/skills catalog and/or packages/mosaic/framework/guides; implementer to resolve the exact skill-markdown source). NOT an in-place ~/.config/mosaic edit (wiped on upgrade). Reviewed PR, author≠reviewer, CI-green where applicable.

Acceptance criteria

  • mosaic-orchestrator skill "Worker Launch Rules" states the WHY (yolo bypasses prompts; stuck dialog = mis-launch → relaunch, not hand-approve) prominently as the #1 rule.
  • Explicit pi/gpt model syntax and Claude syntax present.
  • Change is in the durable framework source (survives mosaic upgrade), landed via reviewed PR.

Non-goals

No behavior/code change to mosaic yolo itself — documentation only.

## Summary Augment the **mosaic-orchestrator skill → "Worker Launch Rules (MANDATORY)"** so the #1 launch rule is unambiguous. Today it says "Always use `mosaic yolo <agent>` from the project directory" but omits (a) the WHY and (b) the GPT/pi model syntax. That thinness was the direct root cause of a real incident (2026-07-17): a worker (ms-792) mis-launched without `mosaic yolo` sat on permission dialogs, requiring hand-approval, until relaunched under yolo. Requested by Jason (owner, #mos 2026-07-17 21:15Z) via Mos. Small framework-doc change. **Queued behind the MS-LEAD ≤2 goal cap — does NOT preempt #792/#818 or gitwatch; does NOT consume a goal lane.** ## Why this matters `~/.config/mosaic` is NOT a git repo — in-place edits to the installed skill get wiped on upgrade (framework-v3 already proved this). The augmentation must land in the framework SOURCE via a reviewed PR so it survives upgrades. ## Change to make In the mosaic-orchestrator skill's "Worker Launch Rules (MANDATORY)" section, make the launch rule prominent (it is the #1 rule) and add: **WHY:** `mosaic yolo` launches the runtime in dangerous-permissions (bypass) mode. A correctly-launched worker NEVER hits a permission dialog. A worker stuck on a permission prompt = a launch-protocol violation → **relaunch via `mosaic yolo`, do NOT hand-approve the dialog.** **MODEL SYNTAX (explicit):** - Codex / pi: `mosaic yolo pi --model openai-codex/gpt-5.6-{sol,terra}:{high,medium}` - Claude: `mosaic yolo claude` - (existing) `mosaic yolo codex`, `mosaic yolo glm` ## Placement / gates Land in the framework SOURCE under `packages/mosaic` (skill/guide source; candidate areas: `packages/mosaic/src/skills` catalog and/or `packages/mosaic/framework/guides`; implementer to resolve the exact skill-markdown source). NOT an in-place `~/.config/mosaic` edit (wiped on upgrade). Reviewed PR, author≠reviewer, CI-green where applicable. ## Acceptance criteria - mosaic-orchestrator skill "Worker Launch Rules" states the WHY (yolo bypasses prompts; stuck dialog = mis-launch → relaunch, not hand-approve) prominently as the #1 rule. - Explicit pi/gpt model syntax and Claude syntax present. - Change is in the durable framework source (survives `mosaic` upgrade), landed via reviewed PR. ## Non-goals No behavior/code change to `mosaic yolo` itself — documentation only.
jason.woltje added the fleet-enhancement label 2026-07-17 21:23:10 +00:00
jason.woltje commented 2026-07-18 00:17:25 +00:00
Author
Owner
Copy Link

Scope finding (MS-LEAD dispatch pre-flight): the mosaic-orchestrator skill SKILL.md ("Worker Launch Rules") is NOT vendored in mosaicstack/stack — its durable source is the separate repo mosaic/agent-skills (git.mosaicstack.dev/mosaic/agent-skills), installed at ~/.config/mosaic/sources/agent-skills/skills/mosaic-orchestrator/SKILL.md. This repo's ./skills catalog contains mosaic-board / forge / jarvis / macp / prd / prdy / setup-cicd / standards but NOT mosaic-orchestrator. So the placement note ("land under packages/mosaic") does not resolve here — the edit target is the agent-skills repo, or (if the skill is to be vendored into this repo) that is a separate decision. Flagging for placement resolution before dispatch. Holding: per this issue's own note it does not consume an MS goal lane and does not preempt the compaction-refresh build (top priority). (Prior auto-posted comment on this issue was shell-mangled — disregard it; this is the corrected text.)

**Scope finding (MS-LEAD dispatch pre-flight):** the mosaic-orchestrator skill SKILL.md ("Worker Launch Rules") is NOT vendored in `mosaicstack/stack` — its durable source is the separate repo **`mosaic/agent-skills`** (git.mosaicstack.dev/mosaic/agent-skills), installed at `~/.config/mosaic/sources/agent-skills/skills/mosaic-orchestrator/SKILL.md`. This repo's `./skills` catalog contains mosaic-board / forge / jarvis / macp / prd / prdy / setup-cicd / standards but NOT mosaic-orchestrator. So the placement note ("land under packages/mosaic") does not resolve here — the edit target is the **agent-skills** repo, or (if the skill is to be vendored into this repo) that is a separate decision. Flagging for placement resolution before dispatch. Holding: per this issue's own note it does not consume an MS goal lane and does not preempt the compaction-refresh build (top priority). (Prior auto-posted comment on this issue was shell-mangled — disregard it; this is the corrected text.)
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
fleet-enhancement
Fleet-wide reliability/speed/cost improvements surfaced by the nightly enhance pass
No Label fleet-enhancement
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
jason.woltje
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: mosaicstack/stack#823
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?