instar 1.3.290 → 1.3.292

package/src/scaffold/templates/jobs/instar/evolution-proposal-evaluate.md

@@ -14,6 +14,7 @@ tags:
 gate: "curl -sf -H \"Authorization: Bearer $INSTAR_AUTH_TOKEN\" http://localhost:${INSTAR_PORT:-4042}/evolution/proposals?status=proposed 2>/dev/null | python3 -c \"import sys,json; d=json.load(sys.stdin); exit(0 if len(d.get('proposals',[])) > 0 else 1)\""
 toolAllowlist: "*"
 unrestrictedTools: true
+mcpAccess: none
 ---
 Review pending evolution proposals: curl -s http://localhost:${INSTAR_PORT:-4042}/evolution/proposals?status=proposed
 

package/src/scaffold/templates/jobs/instar/failure-analyzer.md

@@ -12,6 +12,7 @@ tags:
   - audit
 toolAllowlist: "*"
 unrestrictedTools: true
+mcpAccess: none
 ---
 Run the weekly Failure-Learning analysis. This job exists because individual failures get fixed and forgotten — this turns the accumulated, attributed record into process-level insight, and closes the loop all the way to a human-approved fix and a verification that the fix worked.
 

package/src/scaffold/templates/jobs/instar/health-check.md

@@ -10,5 +10,6 @@ tags:
   - cat:guardian
 toolAllowlist: "*"
 unrestrictedTools: true
+mcpAccess: none
 ---
 Run a quick health check: verify the instar server is responding (curl http://localhost:${INSTAR_PORT:-4042}/health), check disk space (df -h), and report any issues. Only send a message if something needs attention — silence means healthy. IMPORTANT: If you find issues, describe them in plain conversational language. Never dump raw JSON, field names, error codes, or structured data. The user reads these on their phone — write like you're texting them a quick heads-up. If the health response includes a degradationSummary array, relay those narrative strings directly.

package/src/scaffold/templates/jobs/instar/identity-review.md

@@ -13,6 +13,7 @@ tags:
 gate: curl -sf http://localhost:${INSTAR_PORT:-4042}/health >/dev/null 2>&1 && test -f .instar/soul.md
 toolAllowlist: "*"
 unrestrictedTools: true
+mcpAccess: none
 ---
 Identity review — check your identity coherence and growth.
 

package/src/scaffold/templates/jobs/instar/initiative-digest-review.md

@@ -12,6 +12,7 @@ tags:
   - rollout
 toolAllowlist: "*"
 unrestrictedTools: true
+mcpAccess: none
 ---
 You are running the twice-weekly initiative digest review (Mondays and Thursdays). This is the self-driving half of the InitiativeTracker: it makes sure nothing in flight stalls or is forgotten, and it drives ships-staged features toward default-on — without you (the human) ever having to remember. Be concise; post AT MOST one consolidated, conversational Telegram message, and only when there is genuinely something to decide.
 

package/src/scaffold/templates/jobs/instar/insight-harvest.md

@@ -12,6 +12,7 @@ tags:
 gate: "curl -sf -H \"Authorization: Bearer $INSTAR_AUTH_TOKEN\" http://localhost:${INSTAR_PORT:-4042}/evolution/learnings?applied=false 2>/dev/null | python3 -c \"import sys,json; d=json.load(sys.stdin); exit(0 if len(d.get('learnings',[])) > 0 else 1)\""
 toolAllowlist: "*"
 unrestrictedTools: true
+mcpAccess: none
 ---
 Harvest and synthesize learnings: curl -s http://localhost:${INSTAR_PORT:-4042}/evolution/learnings?applied=false
 

package/src/scaffold/templates/jobs/instar/org-intent-drift-audit.md

@@ -12,6 +12,7 @@ tags:
   - org-intent
 toolAllowlist: "*"
 unrestrictedTools: true
+mcpAccess: none
 ---
 Run a weekly drift audit against your organizational intent. This job exists because the per-message Coherence Gate from Phase 1 catches individual constraint violations, but it can't catch the slow accumulation of borderline-passing messages that collectively drift from intent. That's the Klarna failure mode — every individual review passes the gate's threshold, but the agent has gradually optimized for the wrong objective.
 

package/src/scaffold/templates/jobs/instar/reflection-trigger.md

@@ -10,6 +10,7 @@ tags:
   - cat:learning
 toolAllowlist: "*"
 unrestrictedTools: true
+mcpAccess: none
 ---
 AUTH=$(python3 -c "import json; print(json.load(open('.instar/config.json')).get('authToken',''))" 2>/dev/null)
 

package/src/scaffold/templates/jobs/instar/relationship-maintenance.md

@@ -12,5 +12,6 @@ tags:
   - exec:prompt
 toolAllowlist: "*"
 unrestrictedTools: true
+mcpAccess: none
 ---
 Review all relationship files in .instar/relationships/. Note anyone you haven't heard from in over 2 weeks who has significance >= 3. If there are observations worth surfacing, report them. If everything looks fine, do nothing.

package/src/scaffold/templates/jobs/instar/release-readiness-check.md

@@ -13,6 +13,7 @@ tags:
 gate: curl -sf http://localhost:${INSTAR_PORT:-4042}/health >/dev/null 2>&1
 toolAllowlist: "*"
 unrestrictedTools: true
+mcpAccess: none
 ---
 Run the release-readiness check once. This is a mechanical, near-silent watchdog — do NOT message the user.
 

package/upgrades/1.3.291.md

@@ -0,0 +1,26 @@
+# Upgrade Guide — vNEXT
+
+<!-- assembled-by: assemble-next-md -->
+<!-- bump: patch -->
+
+## What Changed
+
+Fixed PromptGate auto-dismiss repeats for deterministic prompts whose stale text remains visible in the terminal capture after the dismiss key is sent. PromptGate now records successful auto-dismisses separately from normal prompt dedup, keeps that memory across the input reset, and clears it only when the captured pane content changes.
+
+The server records dismiss memory only when the key send reports success. Failed sends do not poison the cache, so a prompt can still be retried if the key was not delivered.
+
+## What to Tell Your User
+
+- **Less repeated modal handling**: "When I dismiss a known-safe terminal prompt for another agent, I should stop pressing the same stale prompt every few seconds while the terminal catches up."
+
+## Summary of New Capabilities
+
+| Capability | How to Use |
+|-----------|-----------|
+| PromptGate successful auto-dismiss memory | Automatic for deterministic auto-dismiss prompts such as known Gemini CLI modals. |
+
+## Evidence
+
+Observed before: after PromptGate successfully auto-dismissed the Gemini package-runner install modal, the stale prompt text remained inside the capture window and PromptGate fired the same auto-dismiss again roughly every monitor cycle.
+
+Observed after: focused PromptGate regression tests verify that a successfully auto-dismissed prompt does not re-fire while pane content is unchanged, that failed sends do not create dismiss memory, and that changed pane content re-arms the same prompt shape.

package/upgrades/1.3.292.md

@@ -0,0 +1,22 @@
+# Upgrade Guide — vNEXT
+
+<!-- assembled-by: assemble-next-md -->
+<!-- bump: patch -->
+
+## What Changed
+
+`JobDefinition.mcpAccess?: 'project' | 'none'` flows frontmatter → InstallBuiltinJobs → per-slug manifest (validateManifest enforces the closed set) → JobScheduler.spawnJobSession → the existing `disableProjectMcp` spawn option (`--strict-mcp-config --mcp-config '{"mcpServers":{}}'`). Out-of-set frontmatter values fail safe to legacy at the installer and fail loud at manifest validation.
+
+## What to Tell Your User
+
+Scheduled background jobs (like the every-5-minutes health check) now start faster and leaner: they no longer boot the project's full MCP toolset (browser automation, remote connectors) that they never use. Jobs that need MCP keep it; nothing changes for your own custom jobs.
+
+## Summary of New Capabilities
+
+- `mcpAccess: none` in a job's frontmatter/manifest spawns its session with zero project MCP servers (claude-code spawns; reuses the proven mentor-loop no-MCP flag). `project` or absent = unchanged legacy behavior.
+- 14 shipped utility jobs (health-check, commitment-detection, correction-analyzer, release-readiness-check, and friends) now declare it; the orchestration jobs (mentor/overseer/evolution-implement) deliberately keep full MCP this round.
+- Existing agents pick the change up automatically on update — built-in job manifests regenerate from the shipped templates.
+
+## Evidence
+
+Grounded census (2026-06-05, live box): 81 standing MCP processes across 14 long-lived sessions — every session boots the full project .mcp.json complement; 14 playwright-mcp nodes ≈1.75GB RSS while exactly ONE session actually drives a browser. Zero shipped job templates reference any MCP tool (grep `mcp__|threadline_|playwright|browser|chrome` across `src/scaffold/templates/jobs/instar/*.md` — no matches). The headless hang hazard this removes is the live-verified mentor-loop stall (~4.5 min at 0.1% CPU on auth-required remote MCP boot → ~9s with the flag, docs/specs/LOOP-SESSION-NO-MCP-SPEC.md). Pinned by `tests/unit/scheduler/job-mcp-access.test.ts` (20 tests: closed-set validation both sides, constructor pass-through/omission, installer derivation incl. typo fail-safe, loader round-trip onto JobDefinition, spawn plumbing all three states, and the 14-template declarations + orchestration-family exclusions); 145 adjacent loader/installer/scheduler/flag tests pass unchanged.

package/upgrades/job-mcp-access.eli16.md

@@ -0,0 +1,5 @@
+# Job sessions stop hauling browser tooling they never use
+
+Every scheduled job (the health check, the commitment scan, and friends) runs as a small one-shot Claude session. Until now, every one of those sessions booted with the project's FULL set of MCP servers attached — the browser-automation server, remote connectors that need interactive login, all of it — even though the shipped jobs only ever use bash and curl. That's wasted startup time on every single run (the health check spawns every five minutes), extra standing processes on the box, and a known hazard: a remote MCP server that wants an interactive login can stall a headless session for minutes (this exact stall already bit the mentor loop once, and that fix is what we reuse here).
+
+A job can now declare `mcpAccess: none` in its definition, which makes its session spawn with zero project MCP servers — the same proven no-MCP spawn flag the mentor loop already uses. Fourteen shipped utility jobs declare it; jobs that don't declare anything behave exactly as before, and any job that genuinely needs MCP just leaves the field off (or says `project`). The orchestration jobs that drive other sessions were deliberately left unchanged this round. A typo'd value never silently changes behavior: the installer treats it as undeclared, and a hand-written bad manifest fails loudly at validation.

package/upgrades/side-effects/job-mcp-access.md

@@ -0,0 +1,51 @@
+# Side-Effects Review — per-job MCP access scoping (`mcpAccess`)
+
+**Version / slug:** `job-mcp-access`
+**Date:** `2026-06-05`
+**Author:** `echo`
+**Second-pass reviewer:** `self-review under the Tier-1 lite lane; the capability-loss question (does any job need MCP?) is addressed explicitly below`
+
+## Summary of the change
+
+`JobDefinition.mcpAccess?: 'project' | 'none'`. When `'none'`, `spawnJobSession` passes the EXISTING `disableProjectMcp` option to `spawnSession` (shipped + verified by the mentor autonomous-fix loop, docs/specs/LOOP-SESSION-NO-MCP-SPEC.md), which emits `--strict-mcp-config --mcp-config '{"mcpServers":{}}'` on claude-code spawns and nothing on other frameworks. The field flows frontmatter → InstallBuiltinJobs → per-slug manifest → validateManifest → manifestToJobDefinition. 14 shipped utility templates declare `mcpAccess: none`.
+
+## Decision-point inventory
+
+- `types.ts JobDefinition.mcpAccess` — add — optional, absent = legacy.
+- `AgentMdJobLoader.ALLOWED_FRONTMATTER_KEYS` — modified — `mcpAccess` joins the closed-set whitelist (deliberate, per the set's own doc).
+- `PerSlugManifest.mcpAccess` + `validateManifest` — add — closed two-value enum, loud throw otherwise.
+- `buildPerSlugManifest` — modified — carries the field; omits the key when undefined.
+- `InstallBuiltinJobs` — modified — derives from frontmatter; out-of-set values → undefined (fail-safe to legacy), then validateManifest re-checks the generated manifest.
+- `JobScheduler.spawnJobSession` — modified — `disableProjectMcp: job.mcpAccess === 'none' ? true : undefined`.
+- 14 templates — modified — `mcpAccess: none` added to frontmatter.
+
+## 1. Direction-of-failure analysis (capability loss)
+
+The risk: a job whose body NEEDS an MCP tool gets spawned without MCP and fails mid-run.
+
+- **Grounding:** zero shipped templates reference `mcp__*`, `threadline_*`, playwright, browser, or chrome (grep across `src/scaffold/templates/jobs/instar/*.md`). The marked 14 are bash/curl-only by construction.
+- **Deliberately unmarked:** the orchestration family (`mentor-onboarding`, all `overseer-*`, `evolution-proposal-implement`) keeps project MCP — they drive sessions/build code and are the apprenticeship machinery; this slice does not touch their spawn behavior.
+- **Custom/user jobs:** never affected — the field is opt-in and absent on every existing user job.
+- **Worst NEW case:** a future template author marks a job `none` then writes a body that wants MCP — the session still runs (built-in tools work; MCP tools are simply absent), the job degrades visibly in its own output rather than hanging. That is strictly better than the current failure direction (auth-required remote MCP can hang the headless boot silently).
+
+## 2. Over-permit
+
+None — the change only ever REMOVES servers from a spawn, never adds; and only for jobs that explicitly opt in.
+
+## 3. Scope deliberately NOT taken
+
+- No default flip: absent stays legacy full-MCP. A future slice may flip instar-origin jobs by default after this one soaks.
+- Topic/chat sessions untouched (capability matters there; the standing-cost problem for those is the idle-reap path, fixed separately by the meaningful-tail work).
+- No per-job CUSTOM MCP subset (`--mcp-config` with a real server list) — only the binary none/project. Subset selection is a follow-up if a real job needs it.
+
+## 4. Migration parity
+
+Built-in templates are re-installed by `installBuiltinJobs()` on every update via `refreshHooksAndSettings()`, and the per-slug manifests are REGENERATED from the templates — existing agents pick up the 14 `mcpAccess: none` declarations on their next update without a dedicated migration. Operator-disabled jobs keep their disabled state (existing `existingEnabled` preservation). No config/hook/skill/CLAUDE.md surface changes.
+
+## 5. Token/cost impact
+
+Strictly negative (saves): every marked job spawn skips MCP server boot (playwright-mcp alone ≈125MB + node startup per spawn; health-check spawns 288×/day). No new LLM calls.
+
+## 6. Rollback
+
+Revert the commit. Manifests regenerate without the field on the next install pass; spawns return to full-project-MCP.

package/upgrades/side-effects/promptgate-auto-dismiss-memory.md

@@ -0,0 +1,91 @@
+# Side-Effects Review — PromptGate auto-dismiss memory
+
+**Version / slug:** `promptgate-auto-dismiss-memory`
+**Date:** `2026-06-05`
+**Author:** `instar-codey`
+**Second-pass reviewer:** `self-review required by PromptGate/session-input surface; concur`
+
+## Summary of the change
+
+PromptGate deterministic auto-dismiss prompts were repeatedly firing when the terminal kept the same dismissed prompt text visible after the dismiss key was sent. The server called `onInputSent()` after auto-dismiss to clear normal cooldown/dedup for the next real prompt, but that also allowed the identical stale prompt to re-emit. This change adds a separate in-memory successful-auto-dismiss cache in `src/monitoring/PromptGate.ts`, records into it from the auto-dismiss consumer in `src/commands/server.ts` only when `sendKey` returns true, and clears it when the captured pane content changes or the session is cleaned up.
+
+## Decision-point inventory
+
+- PromptGate auto-dismiss emission — **modify** — suppresses a previously successful auto-dismiss fingerprint while the pane content is unchanged.
+- Server auto-dismiss consumer — **modify** — records successful auto-dismisses in the detector before resetting normal input state.
+- Normal prompt detection/dedup — **pass-through** — unchanged for prompts without `autoDismissKey`.
+- LLM `NO_PROMPT` cache — **pass-through** — unchanged; this fix is separate from the prior token-burn cache.
+
+---
+
+## 1. Over-block
+
+Legitimate repeated auto-dismiss prompts with byte-identical prompt text in byte-identical pane content will be suppressed until the pane content changes. That is intentional: if the pane has not changed after a successful key send, the visible prompt is stale terminal text, not a new modal. Failed key sends do not enter the cache, so delivery failures can still retry.
+
+---
+
+## 2. Under-block
+
+If the terminal redraws the same prompt with any content change, the cache clears and PromptGate may auto-dismiss again. This is the intended re-arm boundary because a changed pane can represent a real new modal or a re-rendered still-blocking state. The change does not attempt cursor-position analysis; it uses the existing captured-text boundary.
+
+---
+
+## 3. Level-of-abstraction fit
+
+The memory lives inside PromptGate because PromptGate owns prompt fingerprints and dedup semantics. The server remains the right place to decide whether the key send succeeded, so it records successful auto-dismisses after `sendKey` returns true. This avoids placing delivery-success knowledge inside the detector and avoids teaching the server how to fingerprint prompt text.
+
+---
+
+## 4. Signal vs authority compliance
+
+**Required reference:** [docs/signal-vs-authority.md](../../docs/signal-vs-authority.md)
+
+- [ ] No — this change produces a signal consumed by an existing smart gate.
+- [ ] No — this change has no block/allow surface.
+- [x] Yes — but this is deterministic dedup/memoization of a prior successful deterministic auto-dismiss, not a brittle semantic classifier.
+- [ ] Yes, with brittle logic — STOP. Reshape the design.
+
+PromptGate already held authority to emit deterministic auto-dismiss prompts. This change narrows repeat emission for the exact prompt fingerprint after a successful key send. It does not add a new modal detector, approve any new action, or change LLM classification authority.
+
+---
+
+## 5. Interactions
+
+- **Shadowing:** the successful-auto-dismiss cache runs before normal emitted-prompt dedup. It only applies when the match has `autoDismissKey`.
+- **Double-fire:** reduces double-fire by preventing the same stale prompt from re-emitting after `onInputSent()` clears normal dedup.
+- **Races:** if pane content changes before the next tick, the cache clears and the prompt can re-arm. If `sendKey` fails, no cache entry is recorded.
+- **Feedback loops:** no persistent feedback loop. State is per-process and per-session.
+
+---
+
+## 6. External surfaces
+
+Visible behavior changes for agents using PromptGate: repeated auto-dismiss log lines for the same unchanged stale prompt should stop. No API, config, persistent state, migration, Telegram route, dashboard route, or model behavior changes. The server log still records the original auto-dismiss with `sent=true/false`.
+
+---
+
+## 7. Rollback cost
+
+Rollback is a pure code revert and patch release. No state migration or cleanup is needed because dismiss memory is in-memory only. During rollback, the prior repeated auto-dismiss behavior can return for stale terminal captures.
+
+---
+
+## Conclusion
+
+The fix is narrow and tied to the observed failure: successful deterministic auto-dismisses now get a memory layer that survives the normal input reset and is invalidated by real pane-content changes. Focused tests cover successful suppression, failed-send retry, and re-arm on content change.
+
+---
+
+## Second-pass review
+
+**Reviewer:** instar-codey self-review
+**Independent read of the artifact:** concur
+
+I re-read the change as a PromptGate/session-input reviewer. The main risk was suppressing a real prompt after a failed key send; recording only when `sendKey` returns true addresses that. The other risk was never re-arming; clearing on captured content change and cleanup bounds the memory.
+
+---
+
+## Evidence pointers
+
+- Focused unit gate: `npx vitest run tests/unit/PromptGate.test.ts` — 62 tests passed.
+- Regression cases added: successful auto-dismiss suppresses unchanged stale pane text; failed send does not suppress; changed pane content re-arms.