Skip to content

feat(web): Studio Builder PR-3 — connected mode#3

Closed
seanrobertwright wants to merge 21 commits into
feat/studio-builder-pr2-visual-uifrom
feat/studio-builder-pr3-connected-mode
Closed

feat(web): Studio Builder PR-3 — connected mode#3
seanrobertwright wants to merge 21 commits into
feat/studio-builder-pr2-visual-uifrom
feat/studio-builder-pr3-connected-mode

Conversation

@seanrobertwright

Copy link
Copy Markdown
Owner

Summary

  • Problem: The PR-2 builder could only edit throwaway fixtures — no way to load, save, create, rename, or delete a real workflow from the console UI.
  • Why it matters: Authors can now build and maintain workflow YAML visually instead of hand-editing files, completing M1 of the Archon Studio integration.
  • What changed: A connected route (/console/builder[/:name]) that loads/saves real workflows via the existing CRUD endpoints, a project picker, explicit Save with a dirty + nav guard, full create/rename/delete, server-tier validation surfaced into the issue panel, and bundled→Save-as.
  • What did NOT change (scope boundary): No server changes (reuses existing GET/PUT/DELETE /api/workflows/:name, POST /api/workflows/validate, GET /api/commands untouched), no DB, no other package, no production /workflows/builder route. BuilderPage stays a controlled component — its only change is an additive extraIssues prop.

UX Journey

Before

User                    Builder (/console/builder)
────                    ──────────────────────────
opens builder ────────▶ seeds BuilderPage from a FIXTURE (switcher)
edits nodes ──────────▶ in-memory only; header says "load/save lands next milestone"
(no way to persist) ──x  nothing reaches disk

After

User                    BuilderConnected (/console/builder[/:name])
────                    ───────────────────────────────────────────
picks project ────────▶ [resolves cwd; persisted + ?project= deep-link]
opens workflow ───────▶ [loadWorkflow(name,cwd) -> fromWorkflowDefinition]
edits nodes ──────────▶ dirty dot; import+client issues in IssueList
clicks Save ──────────▶ [client-validate -> validateWorkflow -> PUT -> invalidate]
                        [server 400 detail surfaces as a source:'server' issue]
New / Rename / Delete ▶ [create-on-save / new-then-old rename / guarded delete]
bundled workflow ─────▶ [read-only banner; "Save as" writes a project override]
navigates away dirty ─▶ [confirm prompt]; reload dirty -> [beforeunload prompt]

Architecture Diagram

After

ConsoleApp routes
  └─[~] /console/builder[/:name] ── [+] BuilderConnected.tsx
                                       ├── useBuilderProject (localStorage + ?project=)
                                       ├── skills/workflows: load/save/delete/validate  ──> existing /api/workflows*
                                       ├── [+] connect/save-logic.ts (pure: issues, planRename, name validation)
                                       ├── store/cache useEntity + invalidate ; [~] store/keys K.workflow(cwd,name)
                                       └─[~] BuilderPage (additive extraIssues prop) ── IssueList
  [-] BuilderRoute.tsx (fixture route deleted; fixture switcher already lives in PreviewPage)

Connection inventory:

From To Status Notes
ConsoleApp BuilderConnected new mounts builder + builder/:name
BuilderConnected skills/workflows new load/save/delete/validate verbs
skills/workflows /api/workflows* unchanged existing endpoints, no server change
BuilderConnected connect/save-logic new pure issue/rename/name logic
BuilderConnected BuilderPage modified additive extraIssues prop
ConsoleApp BuilderRoute removed fixture route deleted

Label Snapshot

  • Risk: risk: low
  • Size: size: M
  • Scope: web
  • Module: web:console-builder

Change Metadata

  • Change type: feature
  • Primary scope: web

Linked Issue

Validation Evidence (required)

bun run type-check        # exit 0 (all 10 packages)
bun run lint              # exit 0 (zero warnings)
bun run format:check      # exit 0
bun --filter @archon/web test   # 338 pass / 0 fail (incl. 19 new)
bun --filter @archon/web build  # exit 0
  • Evidence: all gates green. bun run validate's only failure is a pre-existing, environment-specific Windows test in @archon/providers (pathKind > broken symlinkEPERM; symlink creation needs Developer Mode/admin). That package is untouched by this PR and the test passes on Linux CI.
  • Skipped: Level-4 manual steps (no DOM/browser test harness — a console house rule); the nav-guard UX and visual surface are manual gates.

Security Impact (required)

  • New permissions/capabilities? No
  • New external network calls? No (reuses existing workflow endpoints)
  • Secrets/tokens handling changed? No
  • File system access scope changed? No (writes go through the existing server-validated PUT, which validates cwd against registered codebases)

Compatibility / Migration

  • Backward compatible? Yes
  • Config/env changes? No
  • Database migration needed? No

Human Verification (required)

  • Verified scenarios: type-check/lint/format/build/tests green; code-reviewed (1 HIGH race + 2 LOW items found and fixed, re-validated).
  • Edge cases checked (unit + reasoning): server 400 → source:'server' issue; blocking client errors gate Save; rename collision/no-op/invalid-name blocked; rename delete-fail → non-fatal warning; bundled Save-as; create-on-save flips to edit mode; controlled-select revert on cancelled nav-guard; beforeunload teardown.
  • What was not verified: live-server Level-4 manual walkthrough (no DOM harness).

Side Effects / Blast Radius (required)

  • Affected subsystems: packages/web/src/experiments/console/ only.
  • Potential unintended effects: none outside the console builder; saving normalizes YAML key order (lossless but not byte-identical — documented).
  • Guardrails: isolation ESLint guard, no-logging rule, 19 unit tests.

Rollback Plan (required)

  • Fast rollback: revert this single commit (af0ba60b); nothing outside the console experiment changes.
  • Feature flags: none (behind the /console/* experiment surface).
  • Observable failure symptoms: builder fails to load/save a workflow; issue panel shows a source:'server' error.

Risks and Mitigations

  • Risk: nav guard does not intercept the browser Back button or external ProjectRail clicks (the app is a non-data <BrowserRouter>, so useBlocker is unavailable).
    • Mitigation: beforeunload + confirm-on-intercept on the builder's own controls; documented as a known limitation; data-router migration is out of scope.
  • Risk: subfoldered workflows don't load via the single-name GET.
    • Mitigation: surfaced as a clear "not found → offer New" empty state; documented; matches PR-2's limitation.

🤖 Generated with Claude Code

Wirasm and others added 21 commits June 26, 2026 13:55
…am00#2033)

* fix(db): create remote_agent_user_ai_prefs in the SQLite schema

The SQLite schema (createSchema() in sqlite.ts) and the Postgres
migration (000_combined.sql) are hand-maintained independently. The
remote_agent_user_ai_prefs table was added to the Postgres migration in
the Phase 3 credentials work but never to the SQLite side, so every
workflow run and chat turn on a SQLite install threw
`no such table: remote_agent_user_ai_prefs`. The error is caught
(config-only fallback) but spams two ERROR log lines per run. It was
invisible on the Postgres VPS and hit every default SQLite user.

Add the table to createSchema(): initSchema() runs it with CREATE TABLE
IF NOT EXISTS on every startup, so fresh and existing SQLite databases
both converge automatically.

Add a schema-parity test asserting that every Archon table in the
Postgres migration is also created by the SQLite schema, allowlisting
only the Postgres-only Better Auth tables. This closes the silent
drift bug-class that let the table go missing in the first place.

* test(db): address PR review on the schema-parity guard

Polish from the multi-agent review (no behavioral change to the fix):

- Consolidate the redundant standalone "user_ai_prefs exists" test into
  the parity test's sanity block via expect(...).toContain(...): same
  independent failure mode (regex silently missing that name), one test
  instead of two. (pr-test-analyzer, code-simplifier)
- Replace the stateful while(re.exec()) loop with sql.matchAll() and drop
  the mutable RegExpExecArray. (code-simplifier)
- Broaden the table-name class to [a-z0-9_] so a future digit-containing
  table name can't slip past the parity check. (code-reviewer)
- Comment accuracy: "Nothing else compares them" was self-contradicting
  once this test merges -> past tense; clarify the bug degraded to
  config-only with ERROR log spam rather than aborting runs.
  (comment-analyzer)
- CLAUDE.md: document that a new table in migrations/000_combined.sql must
  also be mirrored into createSchema() in sqlite.ts -- the dual-schema
  invariant the parity test now enforces. (docs-impact)

* docs(readme): update DB diagram to 14 core tables

The architecture diagram listed 12 tables and was missing User Provider
Keys and User AI Prefs (both added in the credentials epic). Update the
count to 14 core tables, add the two missing entries, and note the
Postgres-only Better Auth tables — reconciling with CLAUDE.md's 18 total
(14 core + 4 Better Auth).

---------

Co-authored-by: Archon Maintainer Bot <maintainer-implementer@archon.local>
…oleam00#1983 hardening) (coleam00#2002)

* fix(server,core): clarify Claude auth posture on per-user installs (coleam00#1983 hardening)

Follow-up hardening to the coleam00#1983/coleam00#1984 investigation. No behavior change for
solo installs; removes the misleading global-auth signal on per-user installs
and makes the not-logged-in case actionable.

- Extract the boot auth-posture decision into pure, testable helpers
  (server/src/boot/claude-auth-posture.ts): `shouldDefaultClaudeGlobalAuth`
  and `hasClaudeBootAuthPosture`. The `CLAUDE_USE_GLOBAL_AUTH=true` boot
  auto-default is now SKIPPED when per-user keys are enabled
  (TOKEN_ENCRYPTION_KEY) — those installs deliver Claude auth per-request, so
  the sentinel was misleading (it made the Claude provider log
  `using_global_auth` on installs that authenticated fine, which derailed the
  coleam00#1983 triage). The boot credential check now treats per-user-keys as a valid
  posture so a per-user-only install (no shared Claude key) doesn't exit(1).
- Fix the stale auth comment in claude/provider.ts: `buildSubprocessEnv` has
  not filtered env tokens since coleam00#1067; document that per-request
  `requestOptions.env` merges last and that CLAUDE_USE_GLOBAL_AUTH is an
  Archon-only boot sentinel the CLI ignores.
- Make the "Not logged in" chat error actionable: carry the SDK error detail
  (not just the subtype) into classifyAndFormatError, and add a not-logged-in
  pattern that names the connect surfaces (Settings → Agents / `claude /login`
  / CLAUDE_API_KEY) instead of leaking the raw CLI string.

Tests: claude-auth-posture.test.ts (env matrix), error-formatter not-logged-in
cases. Solo path unchanged (no creds → still defaults to global auth).

Closes coleam00#1983.

* fix(server): treat CLAUDE_USE_GLOBAL_AUTH=false as opt-out, not auth posture

hasClaudeBootAuthPosture used plain truthiness on the sentinel, so an explicit
CLAUDE_USE_GLOBAL_AUTH=false (which setup.ts writes) wrongly counted as a valid
Claude auth posture and suppressed the no-credentials boot warn/exit. Parse it
enabled-only (=== 'true'), matching the codebase convention (ARCHON_DOCKER,
ARCHON_AUTH_OPEN_SIGNUP). Adds regression tests for the 'false' and
arbitrary-value cases.

Addresses CodeRabbit review on claude-auth-posture.ts.

---------

Co-authored-by: Archon Maintainer Bot <maintainer-implementer@archon.local>
…00#1978)

* feat(core): surface unpushed work in source/ after chat turns

The non-destructive workspace sync (coleam00#1864) deliberately stopped hard-resetting
source/ on every chat tick, which means managed clones can now accumulate
local-only state: commits the AI made in direct chat, or uncommitted edits.
Nothing surfaced that state to the user — syncWorkspace's result was returned
from discoverAllWorkflows and consumed nowhere (debug log only), so work
sitting in source/ could silently be lost to the next worktree creation,
manual checkout, or re-clone.

After each completed chat turn on a conversation with an Archon-managed
codebase, check source/ for unpushed commits and uncommitted changes and emit
a one-line system event telling the user to push. Locally-registered repos
are exempt — that is the user's own working directory.

New @archon/git helpers: getCurrentBranch (null on detached HEAD or any
error) and countCommitsAhead (0 on any error, so the reminder stays silent
rather than spuriously warning). The reminder itself is non-fatal by
construction: failures are logged at warn and never obscure the reply the
user just received.

Salvaged from PR coleam00#1860, whose core sync changes were superseded by coleam00#1864.
The reminder test mocks @archon/git via mock.module, so it runs as its own
bun test invocation in @archon/core's test script (mock isolation rules).

* fix(git): log on unexpected countCommitsAhead failure

The catch block returned 0 silently, hiding permission errors, git corruption,
a missing git binary, or path issues during troubleshooting. Keep the safe
0 default (so the post-message reminder stays silent on "I don't know") but
add a debug log, matching the getCurrentBranch pattern in the same file.

Addresses CodeRabbit review on branch.ts.

---------

Co-authored-by: Archon Maintainer Bot <maintainer-implementer@archon.local>
…oleam00#1758) (coleam00#1771)

`git worktree add` without --no-track sets branch.<name>.merge, so a later
`gh pr view` with no PR number resolves to the BASE branch's PR via upstream
config — mis-targeting PR operations in workflow nodes. Pass --no-track on the
new-branch worktree-add (and its fallback path) so the managed branch carries
no upstream, plus a negative test asserting it. Updates the affected default
workflows accordingly.

Review fix (CodeRabbit): guard the create-pr snippet in archon-fix-github-issue
against an empty PR_NUMBER before `gh pr view`, matching the verify-pr-base guard.

Rebased onto dev; the simplify/revert churn collapses into the net change and
the bundled defaults are regenerated.

Co-authored-by: Archon Maintainer Bot <maintainer-implementer@archon.local>
… warn on cold resume (coleam00#1842)

Adds a `resumed?: boolean` field to the provider result-chunk contract and a
shared withResumedOutcome/resumedOutcome helper so every provider records
whether a requested session resume was honored:
  - true    resume requested and the prior session was restored
  - false   resume requested but the provider fell back to a fresh (cold) session
  - omitted no resume was requested

Claude (resumes-or-errors), Codex, OpenCode, and Pi all stamp the outcome. The
dag-executor surfaces a one-time warning (and user message) when a node's
requested resume comes back cold, instead of silently continuing as a normal
fresh turn. It does NOT replay the node — every provider's cold fallback is
already a clean fresh-context run.

Rebased onto dev: the resumed signal was independently referenced for logging in
pi/copilot/opencode; this unifies it on the typed result-chunk field. The
earlier replay-then-revert commits collapse into the shipped warn-on-cold path.

Review fixes (CodeRabbit):
- codex: stamp resumed from the attempt that produced the result — a retry
  re-runs on a fresh startThread (cold), so a cold retry no longer reports
  resumed:true even when the initial resumeThread succeeded (+ regression test).
- dag-executor: mask the session id in the cold-resume warn log (8-char preview,
  matching the node_session_resumed event policy).
- claude test: assert resumed is absent (not present-but-undefined) when no
  resume was requested.

Co-authored-by: Archon Maintainer Bot <maintainer-implementer@archon.local>
…coleam00#1922)

* Fix: persist non-web platform messages to remote_agent_messages (coleam00#1182)

GitHub/Telegram/Discord/Slack conversations replied successfully on their
native platform but appeared empty in the Web UI because the orchestrator
deferred all persistence to platform adapters, and only the web adapter
implemented it (via its API route + MessagePersistence buffer).

Changes:
- Persist inbound user message in handleMessage() for non-web adapters,
  guarded by !isWebAdapter to avoid double-write with the web route
- Persist outbound assistant reply in handleStreamMode() and
  handleBatchMode() after platform.sendMessage(), same guard
- All three writes are fire-and-forget — a DB failure logs a warn and
  does not break platform delivery
- Add regression tests covering non-web batch + stream persistence,
  web non-double-persist, and graceful behavior when the DB rejects

Fixes coleam00#1182

* fix: address review findings from PR coleam00#1922

- Replace mockClear() with mockReset() + mockImplementation(() => Promise.resolve())
  for mockAddMessage in beforeEach — prevents rejection implementation leaking to
  future tests (matches mockReset pattern used for all other mocks in the block)
- Remove dbId alias in handleMessage; use conversation.id directly, consistent
  with the two other addMessage call sites at lines 1485 and 1709
- Fix comment wording: "before invoking the orchestrator" → "already persists
  the user message" to cover all web entry points without over-specifying call order
- Add test: userId propagation to addMessage is asserted
- Add test: stream-mode persistence failure is non-blocking (mirrors existing batch test)

* fix(core): address review findings on non-web message persistence

Review triage for the multi-agent review on this PR:

- Orphaned user rows: moved the inbound user-message persist from the top of
  handleMessage to after the deterministic-command and approval early-returns
  (and before the AI dispatch). Slash commands and approval-only turns no longer
  write a user row with no paired assistant row; AI-bound turns persist the user
  row before the assistant row so created_at ordering is correct. Added a
  regression test for the slash-command path.
- All three persist catches now log errorType: err.constructor.name, matching the
  established logging convention in this file.
- Tests: the stream-mode "delivery not blocked" test now asserts platform.sendMessage
  was actually called (it only checked the promise resolved); the userId test now
  asserts the assistant row carries no userId and that exactly two rows are written.
- Docs: CLAUDE.md messages-table entry documents the split web/non-web write path
  and the user/assistant pairing invariant.

---------

Co-authored-by: Archon Maintainer Bot <maintainer-implementer@archon.local>
* Fix: prevent stale failed workflow auto-resume (coleam00#1549)

Fresh /workflow run commands could silently resume a prior failed run and execute stale persisted args. Gate failed candidates behind explicit user intent while preserving paused approval resume and CAS-owned hydration.

Changes:
- Add force and resumeRunId intent to workflow command dispatch
- Prompt before hydrating failed resume candidates unless explicitly resumed
- Parse /workflow run --force and allow abandoning failed runs
- Add regressions for failed prompts, force, explicit resume, NL approval, and abandon

Fixes coleam00#1549

Co-authored-by: Zolto <zolto@zhome.local>

* fix: address review findings

Fixed:
- Preserve explicit workflow resume identity through dispatch
- Parse escaped quoted slash-command arguments
- Surface workflow load errors during explicit resume

Tests added:
- Parser regression coverage for escaped quoted suggestions
- Resume load-error feedback coverage
- Explicit resume identity and missing working path coverage

Skipped:
- none

* simplify: reduce complexity in changed files

* fix(core): address review findings on stale-resume gating

Review triage for the multi-agent review on this PR:

- Gate prompt is now status-accurate: findResumableRunByParentConversation also
  surfaces stale 'running' orphans, not just 'failed' runs, so the prompt no
  longer hardcodes "Found a prior failed run" — it labels a running orphan
  "interrupted" (+ regression test).
- abandonWorkflow: the inline guard intentionally allows 'failed' (resumable but
  terminal); updated the now-misleading doc comment + "already terminal" message
  to spell out that running/paused/failed are abandonable, and documented why the
  check diverges from TERMINAL_WORKFLOW_STATUSES.
- Missing-working-path resume early-return now logs (orchestrator.resume_missing_working_path)
  instead of returning silently.
- findWorkflowLoadError: dropped the two exact-filename conditions subsumed by the
  extension-strip comparison (dead branches).
- Docs: documented the chat failed-run prompt + `/workflow run --force` escape in
  authoring-workflows; corrected four stale "abandon a non-terminal run" references.

Rejected: the claim that resumeWorkflow() mutates run status before discovery —
it is fetch-and-validate only (no DB write), so there is no stuck-run window.
Deferred: a discriminated-union refactor of the resume-options shape — the
resumeRunId/resumeRun co-reference invariant is satisfied at both call sites
today, so reshaping a public type for a latent-only concern is out of scope here.

---------

Co-authored-by: Zolto <zolto@zhome.local>
Co-authored-by: Archon Maintainer Bot <maintainer-implementer@archon.local>
…leam00#975) (coleam00#1939)

* feat(web): forward SDK lifecycle events to Web UI (tasks + hooks) (coleam00#975)

Implements all 4 phases of issue coleam00#975: forward Claude SDK subagent task
lifecycle and hook callback events to the Web UI through the existing
SSE pipeline.

Phase 1 — packages/providers/src/{types.ts,claude/provider.ts}
  5 new MessageChunk variants (task_started / task_progress /
  task_notification / hook_started / hook_response) carrying the same
  payload the SDK emits. Housekeeping tasks flagged with
  skip_transcript are suppressed at the provider boundary so they never
  reach the UI.

Phase 2 — packages/workflows/src/{event-emitter.ts,dag-executor.ts}
  + packages/server/src/adapters/web/workflow-bridge.ts
  Two new WorkflowEmitterEvent variants (task_activity / hook_activity)
  aggregate the 5 provider chunks into a node-scoped stream; the SSE
  bridge maps them to workflow_task_activity and
  workflow_hook_activity. Both are persisted to workflow_events for
  timeline replay. Slack bridge's exhaustive-check no-op list updated
  to keep the never-narrow intact.

Phase 3 — packages/web/{lib/types.ts,hooks/{useSSE,useDashboardSSE}.ts,
stores/workflow-store.ts,components/workflows/{DagNodeProgress,
ExecutionDagNode,WorkflowDagViewer}.tsx}
  New DagTaskInfo / DagHookInfo arrays under each DagNodeState. SSE
  handlers added; store mutates the same row across the started →
  progress → completed/failed lifecycle so the user sees one entry that
  updates in place. DagNodeProgress renders tasks as a collapsible
  Subagent tasks sub-list and hooks as inline indicators
  (e.g. 'PreToolUse(Bash) → approved'). ExecutionDagNode surfaces
  active/total task and hook counts on the graph card so activity is
  visible without opening the run detail panel.

Phase 4 — packages/providers/src/{types.ts,claude/provider.ts}
  agentProgressSummaries defaults to true for workflow nodes
  (the agentProgressSummaries field is forwarded to Claude SDK
  options). Direct chat calls keep the SDK default (false) so the chat
  surface is unchanged. Authors can opt out per-node with
  agentProgressSummaries: false in nodeConfig.

Tests: 13 new provider tests (chunks + agentProgressSummaries), 6
new bridge mapper tests, 12 new store reducer tests, and new event
variants covered in event-emitter. full `bun run validate` passes
(type-check + lint + format:check + bundled checks + all 1300+ tests).

* fix(web): address CodeRabbit review on SDK lifecycle events

- workflow-store: merge instead of replace when a task/hook row already exists.
  A late `started` (out-of-order after a progress/terminal event was seeded)
  no longer regresses the activity or drops accumulated metadata
  (summary/usage/lastToolName for tasks; outcome/exitCode for hooks). The
  out-of-order seed now also carries the event's metadata so nothing is lost
  before `started` lands. Adds regression tests for both task and hook paths.
- DagNodeProgress: expose collapse state to assistive tech — aria-expanded +
  aria-controls on the toggle button, id on the collapsible region.

---------

Co-authored-by: Archon Maintainer Bot <maintainer-implementer@archon.local>
…am00#2034)

- Project Overview now leads with the governed agentic automation engine (deterministic + LLM steps, approval gates, audit trails). Coding is framed as the current primary surface; general business-operations automation as the direction.
- Rename the 'Single-Developer Tool' principle to 'Single-Tenant per Install': the single-tenant / no-multi-tenant design is reframed as a deliberate one-install-per-client (e.g. one VPS per client) isolation model rather than a limitation, and the multi-user vs multi-tenant distinction is made explicit.
- Add a one-line Product Direction note.

Co-authored-by: Archon Maintainer Bot <maintainer-implementer@archon.local>
…oleam00#2037)

Pulls ~20 releases of Claude Code parity plus a few items that matter here:
- 0.3.178: spawn diagnostics for musl/glibc libc mismatches + pathToClaudeCodeExecutable hint (relevant to binary builds / binary-resolver)
- 0.3.181: richer rate-limit detection fields
- 0.3.191: fast-mode regression fix; per-model weekly-limit usage tracking

Heads-up: 0.3.186 changes background agents to forward permission prompts to
canUseTool instead of auto-denying — smoke-test a workflow that spawns
background agents before merging.

`bun run validate` passes (generated-bundle checks, type-check, lint, format, tests).

Co-authored-by: Archon Maintainer Bot <maintainer-implementer@archon.local>
…2039)

Running the Archon CLI inside Claude Code (or another coding agent) is a
normal, supported way to drive Archon — the silent-hang risk (coleam00#1067) is no
longer live, so the per-run warning was pure noise.

- strip-cwd-env.ts: remove the warning block; keep the CLAUDECODE env strip
- cli.ts / server/index.ts: drop the now-stale "warning emitted here" comments
- configuration.md: remove the ARCHON_SUPPRESS_NESTED_CLAUDE_WARNING row
- troubleshooting.md: replace the "hangs silently / run archon serve" section
  with a focused first-event-timeout entry; note nested runs are supported

The genuine FirstEventTimeoutError in the Claude provider is unchanged.

Co-authored-by: Archon Maintainer Bot <maintainer-implementer@archon.local>
…leam00#2041)

* feat(workflows): experimental Codex/Minimax fix workflows + Pi test workflows

- Add experimental provider variants of archon-fix-github-issue-experimental under
  experimental/: archon-fix-github-issue-codex (Codex/GPT-5.5) and
  archon-fix-github-issue-minimax (MiniMax-M3 via Pi) — identical DAG shape.
- Add Pi/MiniMax-M3 stall diagnostics under test-workflows/: minimax-isolate
  (concurrent, fast idle_timeout), minimax-seq (sequential), minimax-smoke
  (single-prompt reachability).
- Relocate archon-test-pi into test-workflows/.
- Bump maintainer-review-pr Pi model MiniMax-M2.7 -> M3.

* docs(direction): reframe to governed automation engine; single-tenant-per-install

Align direction.md with the merged CLAUDE.md reframe so PR triage stays consistent:
- What Archon IS: 'remote agentic coding platform' -> 'governed agentic automation engine'
  (coding is the mature surface; business-ops is the direction). 'single-developer tool'
  -> 'single-tenant per install' (one install/VPS per client; multi-user supported, distinct
  from multi-tenant). Add always-on automation (native scheduling/triggers) as a planned
  direction. Note the existing community workflow marketplace (the registry where the
  community shares workflows).
- What Archon is NOT: clarify 'not multi-tenant' = not-in-one-install (per-user identity and
  credentials are already in scope). Drop the stale 'not a workflow marketplace' line — a
  community workflow marketplace already exists.
- Open questions: license posture (MIT vs fair-code + CLA), deferred to maintainers.
- Update the §single-developer-tool decline-clause references to §single-tenant-per-install.

---------

Co-authored-by: Archon Maintainer Bot <maintainer-implementer@archon.local>
…arted lines + one-time tier notice (coleam00#2038)

* Fix: surface model-tier resolution to CLI users (coleam00#2036)

After the bundled-workflow rewrite from literal model strings to tier
keywords (small/medium/large), CLI users had no way to see which model a
node actually runs and no signal that tiers exist or are configurable.
This adds two additive, observability-only fixes — model resolution is
unchanged.

Changes:
- Extend NodeStartedEvent with optional provider/model/tier fields
- Thread resolved provider/model/tier from resolveNodeProviderAndModel
  through executeNodeInternal into the emitted (and persisted) node_started
  event; tier is set only when node.model was a tier keyword
- Render the resolved model on the CLI Started line:
  "(claude/opus ← large)" for tiers, "(claude/sonnet)" for literals,
  bare line for bash/script nodes
- Add @archon/paths tier-notice state cache (mirrors update-check, no
  time-based staleness — re-shows only on version change)
- Print a one-time-per-version notice when a CLI run uses unconfigured
  tier keywords, showing each tier's resolved provider/model, the
  plan-dependent 1M note for large→opus, and how to customize; suppressed
  under --quiet
- Tests: event field pass-through, tier-notice cache, CLI render for
  tier/literal/bash node_started lines

Fixes coleam00#2036

* fix(cli): address review findings for tier notice feature

- Fix maybePrintTierNotice missing workflow-level model field: tier-keyword
  workflows setting model at the top level (e.g. `model: large`) were silently
  skipped because the scan only walked nodes, not workflow.model
- Export maybePrintTierNotice and add 8 behavioral unit tests covering all 7
  early-exit paths including workflow-level tier detection, configured tiers,
  version-based suppression, loadConfig failure, and user-prefs coverage
- Add assertions to dag-executor tier test verifying node_started event carries
  tier and model fields to close the end-to-end regression gap
- Replace inline 'small'|'medium'|'large' literals with TierName in
  dag-executor return type and parameter
- Remove dead BUNDLED_VERSION ?? 'dev' null-coalescing (always a string)
- Add debug logging to readTierNoticeState catch and maybePrintTierNotice
  loadConfig catch, matching the update-check.ts pattern
- Fix inaccurate JSDoc: "Mirrors archon ai tier list formatting" → "Uses the
  same 7-char tier column as archon ai tier list"
- Add readTierNoticeState JSDoc note that errors are silently discarded
- Add tier-notice.json to CLAUDE.md and archon-directories.md file inventories

* simplify: replace nested ternary with if/else in renderWorkflowEvent

* fix(workflows): attribute workflow-level tier to inherited nodes

Review of coleam00#2036 found the `← tier` annotation never fired for the bundled
default workflows: their tier lives at the workflow level (e.g. `model: medium`)
while nodes have no own `model`, and the dag-executor only inspected
`node.model` (its `workflow` param type didn't even expose `model`).

- Thread the workflow-level tier keyword through WorkflowLevelOptions into the
  node_started event so inherited-tier nodes surface `← medium` / `← large`.
- Expose `model?` on executeDagWorkflow's `workflow` param type.
- Add a regression test for the workflow-level inheritance path.
- tier-notice: log the buildAiProfile fallback at debug (was a bare catch).

---------

Co-authored-by: Archon Maintainer Bot <maintainer-implementer@archon.local>
… vault (coleam00#2040)

* Fix: zero-config local encryption key for the credential vault (coleam00#2035)

isPerUserProviderKeysEnabled() returned false unless TOKEN_ENCRYPTION_KEY
was set, so `archon ai login`/`key set` and the console connect panel were
permanently disabled on solo/CLI installs even though the vault is fully
built. Auto-provision a local key so the vault is enabled by default.

Changes:
- getEncryptionKey() is now a three-tier resolver: TOKEN_ENCRYPTION_KEY env
  var → ~/.archon/credential-key file → auto-generate + persist (0600).
  readOrCreateLocalKey() never silently regenerates a malformed key file.
- isPerUserProviderKeysEnabled() always returns true (auto-key); the explicit
  env var still wins for managed VPS/multi-user deployments. Per-user GitHub
  stays independently gated on GITHUB_APP_ID + TOKEN_ENCRYPTION_KEY.
- listDecryptedUserProviderCredentials() logs a mass decrypt-failure (all rows)
  at ERROR with a re-connect hint, distinct from the partial-failure WARN.
- `archon doctor` gains a checkConnectedProviders check (connected count or a
  connect hint); `archon ai` gate message updated (now a defensive guard).
- getCredentialKeyPath() added to @archon/paths.
- Tests: resolver-chain + readOrCreateLocalKey coverage, always-on gate,
  doctor check; isolate token-crypto.test.ts into its own bun-test batch and
  extend orchestrator fs/@archon/paths mocks for the new node:fs/path imports.

Fixes coleam00#2035

* fix: address review findings from PR coleam00#2040 code review

- Fix Pino log convention: move human-readable text from mass_decrypt_failure
  message field into structured data object with resolved:0 and hint fields
- Add missing test for mass_decrypt_failure ERROR branch in
  user-provider-key-store.test.ts (was untested, partial-failure WARN path
  had coverage but all-fail ERROR path did not)
- Fix misleading chmodSync comment: "pre-existed" → explains umask dilution
- Fix getEncryptionKey JSDoc to mention both throw paths (env var malformed
  AND key file malformed)
- Add clarifying comment on ENOENT catch explaining undefined !== 'ENOENT'
- Reset cachedLog in clearLocalKeyCache() so test mocks intercept createLogger
  on re-initialization
- Reorder checkConnectedProviders: identity guard before loadDeps() to avoid
  misleading error message and wasted dynamic import
- Add getCredentialKeyPath unit test in archon-paths.test.ts
- Update 5 CLAUDE.md spots removing TOKEN_ENCRYPTION_KEY gate references
- Update ai-assistants.md, cli.md, api.md, security.md, configuration.md to
  reflect that the credential vault is always available (auto-provisioned key)

* simplify: reduce complexity in changed files

* fix(test): cross-platform credential-key path assertion

archon-paths.test.ts hardcoded a POSIX path for getCredentialKeyPath(),
failing on Windows (backslash separators). Build the expected path with
join() to match the sibling getArchon*Path tests.

* test(credentials): guard additive no-scrub for unconnected users (coleam00#2035)

Add the DoD-required regression test: getUserProviderEnv returns an empty
env bag for an unconnected user, so enabling the credential vault (auto-key
on by default) never scrubs ambient ANTHROPIC_API_KEY / OPENAI_API_KEY.

* fix(test): skip POSIX 0600 mode assertion on Windows

statSync().mode reports 0666 on Windows (no POSIX permission bits), so the
credential-key 0600 check is POSIX-only. Guard it for non-win32; the impl
still sets mode 0600 (honored on POSIX, harmlessly ignored on Windows).

---------

Co-authored-by: Archon Maintainer Bot <maintainer-implementer@archon.local>
* chore: update Homebrew formula for v0.3.9

* chore(release-skill): use --help (not version) for Step 1.5 smoke probe (#1359)

The pre-flight binary smoke does a bare `bun build --compile` — it
deliberately skips `scripts/build-binaries.sh` to stay fast. That means
packages/paths/src/bundled-build.ts retains its dev defaults, including
BUNDLED_IS_BINARY = false.

version.ts branches on BUNDLED_IS_BINARY: when true it returns the
embedded string; when false it calls getDevVersion(), which reads
package.json at `SCRIPT_DIR/../../../../package.json`. Inside a compiled
binary SCRIPT_DIR resolves under `$bunfs/root/`, the walk produces a CWD-
relative path that doesn't exist, and the smoke aborts with "Failed to
read version: package.json not found" — a false positive.

Hit during the 0.3.8 release attempt: the real Pi lazy-load fix was
working end-to-end; the smoke test was the only thing failing.

Use --help instead. It exercises the same module-init graph (so it still
catches the real failure modes the skill lists — Pi package.json init
crash, Bun --bytecode bugs, CJS wrapper issues, circular imports under
minify) but has no dev/binary branch, so no false positive.

Also add a longer comment block explaining why --help is preferred, so
this doesn't get "normalized" back to `version` by a future drive-by.

* chore(test-release-skill): preserve archon-stable across test cycles

The brew path of /test-release runs `brew uninstall` in Phase 5 to leave the
system in its pre-test state. For operators using the dual-homebrew pattern
(renamed brew binary at `/opt/homebrew/bin/archon-stable` so it coexists with
a `bun link` dev `archon`), that uninstall wipes the Cellar dir the
`archon-stable` symlink points into → `archon-stable` becomes dangling →
`brew cleanup` sweeps it away on the next brew op. Next time the operator
wants stable, they have to manually re-run `brew-upgrade-archon`.

Fix: make the skill aware of `archon-stable` and restore it transparently.

- Phase 2 item 4: detect the `archon-stable` symlink before any brew op;
  export `ARCHON_STABLE_WAS_INSTALLED=yes` so Phase 5 knows to restore it.
  Only triggers for the brew path (curl-mac/curl-vps don't touch brew so
  they leave `archon-stable` alone).
- Phase 5 brew path: after `brew uninstall + untap`, if the flag was set,
  re-tap + re-install + rename. Verifies the restored `archon-stable`
  reports a version and warns (non-fatal) if the rename target is missing.
  Documents the tradeoff: the restored version is "whatever the tap ships
  today", not necessarily the pre-test version — usually that's what the
  operator wants (the release they just tested becomes stable) but the
  back-version-QA case requires a manual `brew-upgrade-archon` after.
- Phase 1 confirmation banner now mentions that `archon-stable` will be
  preserved so the operator isn't surprised by the reinstall during Phase 5.

No changes to curl-mac/curl-vps paths. No changes to Phase 4 test suite.

* fix(providers/pi): install PI_PACKAGE_DIR shim so Pi workflows run in a compiled binary (#1360)

v0.3.9 made Pi boot-safe: lazy-loading its imports meant `archon version`
no longer crashed on `@mariozechner/pi-coding-agent/dist/config.js`'s
module-init `readFileSync(getPackageJsonPath())`. That's what the
`provider-lazy-load.test.ts` regression test guards.

The fix was only half the problem though. When a Pi workflow actually
runs, sendQuery() triggers the dynamic import — and Pi's config.js
module-init fires then, hitting the exact same ENOENT on
`dirname(process.execPath)/package.json`. Discovered by running
`archon workflow run test-pi` against a locally-compiled 0.3.9 binary:

    [main] Failed: ENOENT: no such file or directory,
           open '/private/tmp/package.json'
        at readFileSync (unknown)
        at <anonymous> (/$bunfs/root/archon-providertest:184:7889)
        at init_config

Boot-safe ≠ runtime-safe. The `/test-release` run for 0.3.9 passed
because it only exercised `archon-assist` (Claude); Pi was never
actually invoked on the released binary.

Fix: before the dynamic `import('@mariozechner/pi-coding-agent')` in
sendQuery, install a PI_PACKAGE_DIR shim. Pi's config.js checks
`process.env.PI_PACKAGE_DIR` first in its `getPackageDir()` and
short-circuits the `dirname(process.execPath)` walk. We write a
minimal `{name, version, piConfig:{}}` stub to
`tmpdir()/archon-pi-shim/package.json` (idempotent — existsSync check)
and set the env var. Pi only reads `piConfig.name`, `piConfig.configDir`,
and `version` from that file, all optional, so the stub surface is
genuinely minimal.

Localized to PiProvider: no global state, no mutation of any shared
config, no upstream fork. Claude and Codex providers are unaffected
(their SDKs don't have this class of module-init side effect).

Verified end-to-end: built a compiled archon binary with this patch,
ran `archon workflow run test-pi --no-worktree` (Pi workflow with
model `anthropic/claude-haiku-4-5`), got a clean response. Before the
patch, same binary crashed at `dag_node_started` with the ENOENT above.

Regression test added: asserts `PI_PACKAGE_DIR` is set after sendQuery
hits even its fast-fail "no model" path. Together with the existing
`provider-lazy-load.test.ts` (boot-safe) this covers both halves.

* feat(providers): autodetect canonical binary install paths for Claude and Codex (#1361)

Both binary resolvers previously stopped at env-var + explicit config and
threw a "not found" error when neither was set. Users who followed the
upstream-recommended install flow (Anthropic's `curl install.sh` for
Claude, `npm install -g @openai/codex`) still had to manually set either
`CLAUDE_BIN_PATH` / `CODEX_BIN_PATH` or the corresponding config field
before any workflow could run.

Add a tier-N autodetect step between the explicit config tier and the
install-instructions throw. Purely additive: env and config still win
when set (precedence covered by new tests). On autodetect miss, the same
install-instructions error fires as before.

Claude probe list (verified against docs.claude.com "Uninstall Claude
Code → Native installation" section):
  - $HOME/.local/bin/claude            (mac/linux native installer)
  - $USERPROFILE\.local\bin\claude.exe (Windows native installer)

Codex probe list (verified against openai/codex README; npm global-
install puts the binary at `{npm_prefix}/bin/<name>` on POSIX,
`{npm_prefix}\<name>.cmd` on Windows):
  - $HOME/.npm-global/bin/codex   (user-set `npm config set prefix`)
  - /opt/homebrew/bin/codex       (mac arm64 with homebrew-node)
  - /usr/local/bin/codex          (mac intel / linux system node)
  - %APPDATA%\npm\codex.cmd       (Windows npm global default)
  - $HOME\.npm-global\codex.cmd   (Windows user-set prefix)

Not probed (explicit override still required):
  - Custom npm prefixes — `npm root -g` would need a subprocess per
    resolve, too much surface for a probe helper
  - `brew install --cask codex` — cask layout isn't a PATH binary
  - Manual GitHub Releases extracts — placement is user-determined
  - `~/.bun/bin/codex` — not documented in openai/codex README

Pi provider intentionally has no equivalent change: the Pi SDK is
bundled into the archon binary (no subprocess), so there's no "binary"
to resolve. Pi auth lives at `~/.pi/agent/auth.json` which the SDK
already finds by default, and the PR A shim (`PI_PACKAGE_DIR`) handles
the package-dir case via Pi's own documented escape hatch.

E2E verified: removed both config entries from ~/.archon/config.yaml,
rebuilt compiled binary, ran `archon workflow run archon-assist` and a
Codex workflow. Logs showed `source: 'autodetect'` for both, responses
returned cleanly.

* fix(providers/test): use os.homedir() instead of $HOME in claude binary autodetect test

The native-installer autodetect test computed its expected path from
process.env.HOME, but the implementation uses node:os homedir(). On
Windows, HOME is typically unset (Windows uses USERPROFILE), so the
test fell back to '/Users/test' while the resolver returned the real
home dir — making the spy's path-equality check fail and breaking CI
on windows-latest.

Mirror the implementation by importing homedir() from node:os and
joining with node:path so the expected path matches the actual
platform-resolved home and separator.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

* fix(server): contain Discord login failure so it doesn't kill the server (#1365)

Reported in #1365: a user running `archon serve` with DISCORD_BOT_TOKEN
set but the "Message Content Intent" toggle disabled in the Discord
Developer Portal saw the entire server crash with `Used disallowed
intents`. Discord rejects the gateway connection (close code 4014) when
a privileged intent is requested without being enabled, and the
unguarded `await discord.start()` propagated the error all the way up,
taking the web UI down with it.

Wrap discord.start() in try/catch — log the failure with an actionable
hint (special-cased for the disallowed-intent error) and continue
running. Other adapters and the web UI come up regardless. The shutdown
handler already uses optional chaining (`discord?.stop()`) so nulling
discord after a failed start is safe.

Other adapters (Telegram, Slack, GitHub, Gitea, GitLab) have the same
unguarded-start pattern but are out of scope for this fix — addressing
them is tracked separately.

Also expanded the Discord setup docs with a caution callout that names
the exact error string and the new log event so users can grep for
both.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

* docs(script-nodes): dedicated guide + teach the archon skill (#1362)

* docs(script-nodes): add dedicated guide and teach the archon skill how to write them

Script nodes (script:) have been a first-class DAG node type since v0.3.3 but
were documented only as one-liners in CLAUDE.md and a CI smoke test. Claude
Code reading the archon skill would see "Four Node Types: command, prompt,
bash, loop" and reach for bash+node/python one-liners instead of a proper
script node — losing bun's --no-env-file isolation, uv's --with dependency
pins, and the .archon/scripts/ reuse story.

- New packages/docs-web/src/content/docs/guides/script-nodes.md mirroring the
  structure of loop-nodes.md / approval-nodes.md: schema, inline vs named
  dispatch, runtime/deps semantics, scripts directory precedence (repo > home),
  extension-runtime mapping, env isolation, stdout/stderr contract, patterns,
  and the explicit list of ignored AI fields.
- guides/authoring-workflows.md and guides/index.md updated so the new guide is
  discoverable from both the node-types table and the guides landing page.
- reference/variables.md calls out the no-shell-quote difference between
  bash: and script: substitution — a subtle correctness trap when adapting a
  bash pattern into a script node.
- Sidebar order bumped +1 on hooks/mcp-servers/skills/global-workflows/
  remotion-workflow to slot script-nodes at order 5 next to the other
  node-type guides.

- .claude/skills/archon/SKILL.md: replaces stale "Four Node Types" (which
  also silently omitted approval and cancel) with the accurate seven, with a
  script-node code block showing both inline and named patterns.
- references/workflow-dag.md: full Script Node section covering dispatch,
  resolution, deps, stdout contract, and the list of AI-only fields that are
  ignored; validation-rules list updated.
- references/dag-advanced.md and references/variables.md: retry-support line
  corrected; no-shell-quote note added.
- examples/dag-workflow.yaml: added an extract-labels TypeScript script node
  and updated the header comment.

* fix(docs): review follow-ups for script-node guide

- skills example: extract-labels was reading process.env.ISSUE_JSON which is
  never set; use String.raw`$fetch-issue.output` so the upstream bash node's
  JSON is actually consumed
- guides/script-nodes.md + skills/workflow-dag.md: idle_timeout is accepted
  but ignored on script (and bash) nodes — executeScriptNode only reads
  node.timeout. Clarify that script/bash use `timeout`, not idle_timeout
- archon-workflow-builder.yaml: prompt enumerated only bash/prompt/command/loop,
  so the AI builder could never propose script or approval nodes. Add both
  (plus examples + rule about script output not being shell-quoted) and
  regenerate bundled defaults
- book/dag-workflows.md + book/quick-reference.md + adapters/web.md: fill in
  the node-type references that were missing script, approval, and cancel.
  adapters/web.md also overclaimed "loop" in the palette — NodePalette.tsx
  only drags command/prompt/bash, so note that the other kinds are YAML-only

* docs/skill: general hardening — fix inaccuracies, fill workflow/CLI/env gaps, add good-practices + troubleshooting (#1363)

* fix(skill/when): document the full `when:` operator set and compound expressions

The skill reference previously stated "operators: ==, != only" which is
materially wrong — the condition evaluator supports ==, !=, <, >, <=, >=
plus && / || compound expressions with && binding tighter than ||, plus
dot-notation JSON field access. An agent authoring a workflow from the
skill would think half the operators don't exist.

Replaces the single-sentence section with a structured reference covering:
- All six comparison operators (string and numeric modes)
- Compound expressions with precedence rules and short-circuit eval
- JSON dot notation semantics and failure modes
- The fail-closed rules in full (invalid expression, non-numeric side,
  missing field, skipped upstream)

Grounded in packages/workflows/src/condition-evaluator.ts.

* feat(skill): document Approval and Cancel node types

Approval and cancel nodes are first-class DAG node types (approval since the
workflow lifecycle work in #871, cancel as a guarded-exit primitive) but the
skill never described either one. An agent reading the skill and asked to
"add a review gate before implementation" or "stop the workflow if the input
is unsafe" would fall back to bash + exit 1, losing the proper semantics
(cancelled vs. failed, on_reject AI rework, web UI auto-resume).

Approval node coverage (references/workflow-dag.md, SKILL.md):
- Full configuration block with message, capture_response, on_reject
- The interactive: true workflow-level requirement for web UI delivery
- Approve/reject commands across all platforms (CLI, slash, natural
  language) and the capture_response → $node-id.output flow
- Ignored-fields list + the on_reject.prompt AI sub-node exception

Cancel node coverage (references/workflow-dag.md, SKILL.md):
- Single-field schema (cancel: "<reason>")
- Lifecycle: cancelled (not failed); in-flight parallel nodes stopped;
  no DAG auto-resume path
- The "cancel: vs bash-exit-1" decision rule (expected precondition miss
  vs. check itself failing)
- Two canonical patterns — upstream-classification gate, pre-expensive-step
  gate

Validation-rules list updated to enumerate approval/cancel constraints
(message non-empty, on_reject.max_attempts range 1-10, cancel reason
non-empty), plus a forward note that script: joins the mutually-exclusive
set once PR #1362 lands.

Placement in both files is after the Loop section and before the validation
section, so this commit stays additive with respect to PR #1362's Script
node insertion between Bash and Loop — rebase is clean.

* feat(skill): document workflow-level fields beyond name/provider/model

The skill's Schema section previously showed only name, description, provider,
and model at the workflow level — which is most of a stub. Agents asked to
"use the 1M-context Claude beta" or "run this under a network sandbox" or
"add a fallback model in case Opus rate-limits" had no way to discover
that any of these fields existed at the workflow level.

Adds a comprehensive Workflow-Level Fields section covering:
- Core: name, description, provider, model, interactive (with explicit
  callout that interactive: true is REQUIRED for approval/loop gates on
  web UI — a common footgun)
- Isolation: worktree.enabled for pin-on/pin-off (the only worktree field
  at workflow level; baseBranch/copyFiles/path/initSubmodules are
  config.yaml only, so a cross-reference points there)
- Claude SDK advanced: effort, thinking, fallbackModel, betas, sandbox,
  with explicit per-node-only exceptions (maxBudgetUsd, systemPrompt)
- Codex-specific: modelReasoningEffort (with note that it's NOT the same
  as Claude's effort — this has confused users), webSearchMode,
  additionalDirectories
- A complete worked example combining sandbox + approval + interactive

All fields cross-referenced against packages/workflows/src/schemas/workflow.ts
and packages/workflows/src/schemas/dag-node.ts.

* feat(skill/loop): document interactive loops and gate_message

Interactive loop nodes pause between iterations for human feedback via
/workflow approve — used by archon-piv-loop and archon-interactive-prd.
The skill's Loop Nodes section previously omitted both interactive: true
and gate_message entirely, so an agent writing a guided-refinement
workflow wouldn't know the feature exists or that gate_message is
required at parse time.

Adds:
- interactive and gate_message rows to the config table (marking
  gate_message as required when interactive: true — enforced by the
  loader's superRefine)
- A dedicated "Interactive Loops" subsection explaining the 6-step
  iterate-pause-approve-resume flow
- Explicit call-out that $LOOP_USER_INPUT populates ONLY on the first
  iteration of a resumed session — easy to miss and a common surprise
- Workflow-level interactive: true requirement for web UI delivery
  (loader warning otherwise) so the full-flow example is complete
- Note that until_bash substitution DOES shell-quote $nodeId.output
  (unlike script bodies) — called out since the audit surfaced this
  inconsistency

* fix(skill/cli): complete the CLI command reference with missing lifecycle commands

The CLI reference previously documented only list, run, cleanup, validate,
complete, version, setup, and chat — missing nearly every workflow
lifecycle command an agent needs to operate a paused, failed, or stuck
run. The interactive-workflows reference assumed these commands existed
without actually documenting them.

Adds full documentation for:
- archon workflow status — show running workflow(s)
- archon workflow approve <run-id> [comment] — resume approval gate
  (also populates $LOOP_USER_INPUT on interactive loops and the gate
  node's output when capture_response: true)
- archon workflow reject <run-id> [reason] — reject gate; cancels or
  triggers on_reject rework depending on node config
- archon workflow cancel <run-id> — terminate running/paused with
  in-flight subprocess kill
- archon workflow abandon <run-id> — mark stuck row cancelled without
  subprocess kill (for orphan-cleanup after server crashes — matches
  the #1216 precedent)
- archon workflow resume <run-id> [message] — force-resume specific
  run (auto-resume is default; this is for explicit override)
- archon workflow cleanup [days] — disk hygiene for old terminal runs
  (with explicit callout that it does NOT transition 'running' rows,
  a common confusion)
- archon workflow event emit — used inside loop prompts for state
  signalling; documented so agents don't invent their own mechanism
- archon continue <branch> [flags] [msg] — iterative-session entry
  point with --workflow and --no-context flags

Also:
- Adds --allow-env-keys flag to the `workflow run` flag table with
  audit-log context and the env-leak-gate remediation use case
- Adds an "Auto-resume without --resume" note disambiguating when
  --resume is needed vs. when auto-resume handles it
- Adds --include-closed flag to `isolation cleanup`, which was
  previously missing; converts the flag list to a structured table
- Explains the cancel/abandon distinction (live subprocess vs. orphan)

All grounded in packages/cli/src/commands/workflow.ts, continue.ts,
and isolation.ts.

* feat(skill/repo-init): add scripts/ and state/, three-path env model, per-project env injection

The repo-init reference was missing two first-class .archon/ directories
(scripts/ since v0.3.3, state/ since the workflow-state feature) and had
nothing to say about env — the #1 thing a user hits on first-run when
their repo has a .env file with API keys.

Directory tree updates:
- Adds .archon/scripts/ with the extension->runtime rule (.ts/.js -> bun,
  .py -> uv) so agents know where to put named scripts referenced by
  script: nodes.
- Adds .archon/state/ with explicit "always gitignore" callout — these
  are runtime artifacts, not source. Previously undocumented in the skill.
- Adds .archon/.env (repo-scoped Archon env) and distinguishes it from
  the target repo's top-level .env.
- Adds a "What each directory is for" list so the structure isn't just
  a tree with no narrative.

.gitignore guidance:
- state/ and .env added as must-gitignore (state/ matches CLAUDE.md and
  reference/archon-directories.md — skill was lagging).
- mcp/ demoted to conditional — gitignore only if you hardcode secrets.

New "Three-Path Env Model" section:
- ~/.archon/.env (trusted, user), <cwd>/.archon/.env (trusted, repo),
  <cwd>/.env (UNTRUSTED, target project — stripped from subprocess env).
- Precedence (override: true across archon-owned paths) and the
  observable [archon] loaded N keys / stripped K keys log lines so
  operators can verify what actually happened.
- Decision tree for where to put API keys vs. target-project env vs.
  things Archon shouldn't touch.
- Links to archon setup --scope home|project with --force for writing
  to the right file with timestamped backups.

New "Per-Project Env Injection" section:
- Documents both managed surfaces: .archon/config.yaml env: block
  (git-committed, $REF expansion) and Web UI Settings → Projects →
  Env Vars (DB-stored, never returned over API).
- Names every execution surface that receives the injected vars:
  Claude/Codex/Pi subprocess, bash: nodes, script: nodes, and direct
  codebase-scoped chat.
- Documents the env-leak gate with all 5 remediation paths so an agent
  hitting "Cannot register: env has sensitive keys" knows the options.

Grounded in CHANGELOG v0.3.7 (three-path env + setup flags), v0.3.0
(env-leak gate), and reference/security.md on the docs site.

* fix(skill/authoring-commands): correct override paths and add home-scoped commands

The file-location and discovery sections described an override layout that
does not match the actual resolver. It showed:

  .archon/commands/defaults/archon-assist.md  # Overrides the bundled

and claimed `.archon/commands/defaults/` was where repo-level overrides
lived. In fact the resolver (executor-shared.ts:152-200 + command-
validation.ts) walks `.archon/commands/` 1 level deep and uses basename
matching — putting `archon-assist.md` at the top of `.archon/commands/`
is the canonical way to override the bundled version. The `defaults/`
subfolder is a Archon-internal convention for shipping bundled defaults,
not a user-facing override pattern.

Also, home-scoped commands (`~/.archon/commands/`, shipped in v0.3.7)
were completely absent — agents authoring personal helpers wouldn't
know they could live at the user level and be shared across every repo.

Changes:
- File Location section now shows all three discovery scopes (repo,
  home, bundled) with precedence ordering and 1-level subfolder rules
- Duplicate-basename rule documented as a user error surface
- Discovery and Priority section rewritten with accurate 3-step lookup
  order — no more references to the nonexistent defaults/ override path
- Adds the Web UI "Global (~/.archon/commands/)" palette label note so
  users authoring helpers for the builder know what to expect

No code changes — this is a pure fix of stale/incorrect skill reference
material.

* feat(skill): add workflow good-practices and troubleshooting reference pages

Closes two gaps from the audit. The skill previously had zero guidance on
designing multi-node workflows (what to avoid, what to reach for first,
how to structure artifact chains) and zero guidance on where to look
when things go wrong (log paths, env-leak gate remediations, orphan-row
cleanup, resume semantics).

New references/good-practices.md (9 Good Practices + 7 Anti-Patterns):

- Use deterministic nodes (bash:/script:) for deterministic work, AI for
  reasoning — the single biggest quality lever
- output_format required whenever downstream when: reads a field — the
  most common source of "workflow silently routes wrong"
- trigger_rule: none_failed_min_one_success after conditional branches —
  the classic bug where all_success fails because a skipped when:-gated
  branch doesn't count as a success
- context: fresh requires artifacts for state passing — commands must
  explicitly "read $ARTIFACTS_DIR/..." when downstream of fresh
- Cheap models (haiku) for glue, strong for substance
- Workflow descriptions as routing affordances
- Validate (archon validate workflows) + smoke-run before shipping
- Artifact-chain-first design
- worktree.enabled: true for code-changing workflows (reversibility)
- Anti-patterns with before/after YAML examples for each (AI-for-tests,
  free-form when: matching, context: fresh without artifacts, long flat
  AI-node layers, secrets in YAML, retry on loop nodes, tiny
  max_iterations, missing workflow-level interactive:, tool-restricted
  MCP nodes)

New references/troubleshooting.md:

- Log location (~/.archon/workspaces/<owner>/<repo>/logs/<run-id>.jsonl)
  with jq recipes for common queries (last assistant message, failed
  events, full stream)
- Artifact location for cross-node handoff debugging
- 9 Common Failure Modes, each with root cause + concrete fix:
  - $BASE_BRANCH unresolvable
  - Env-leak gate (5 remediations)
  - Claude/Codex binary not found (compiled-binary-only)
  - "running" forever (AI working / orphan / idle_timeout)
  - Mid-workflow failure and auto-resume semantics
  - Approval gate missing on web UI (workflow-level interactive:)
  - MCP plugin connection noise (filtered by design)
  - Empty $nodeId.output / field access (4 causes)
- Diagnostic command cheat sheet (list, status, isolation list, validate,
  tail-log, --verbose, LOG_LEVEL=debug)
- Escalation protocol (version + validate + log tail + CHANGELOG + issue)

SKILL.md routing table now dispatches "Workflow good practices /
anti-patterns" and "Troubleshoot a failing / stuck workflow" to the new
references so an agent can find them without having to know they exist.

* docs(book): update node-types coverage from four to all seven

The book is the curated first-contact reading path (landing page → "Get
Started" → /book/). Both dag-workflows.md and quick-reference.md were
stuck on "four node types" — missing script, approval, and cancel. A user
reading the book as their first introduction would form an incomplete
mental model, then find three more node types in the reference section
later with no explanation of when they arrived.

book/dag-workflows.md:
- "four node types" → "seven node types. Exactly one mode field is
  required per node"
- Table now lists Command, Prompt, Bash, Script, Loop, Approval, Cancel
  with one-line "when to use" for each, and cross-links to the dedicated
  guide pages for Script / Loop / Approval
- New sections below the table for Script (inline + named examples with
  runtime and deps), Approval (with the interactive: true workflow-level
  note that's easy to miss), and Cancel (guarded-exit pattern) — keeping
  the existing narrative shape for Bash and Loop

book/quick-reference.md:
- Node Options table now includes script, approval, cancel rows
- agents row added (inline sub-agents, Claude-only)
- New "Script-specific fields" and "Approval-specific fields" subsections
  so the cheat-sheet is actually complete rather than pointing users
  elsewhere for the required constraints
- Retry row callout that loop nodes hard-error on retry — previously
  omitted
- bash timeout note widened to cover script timeout (same semantics)

Both files are docs-web content; the CI build on the docs-script-nodes
PR (#1362) previously validated the Starlight build path with a similar
table addition, so this should render clean.

* fix(skill/cli): remove nonexistent \`archon workflow cancel\`, fix workflow status jq recipe

Two accuracy issues from the PR code-reviewer (comment 4311243858).

C1: \`archon workflow cancel <run-id>\` does NOT exist as a CLI subcommand.
The switch at packages/cli/src/cli.ts:318-485 dispatches on list / run /
status / resume / abandon / approve / reject / cleanup / event — running
\`archon workflow cancel\` hits the default case and exits with "Unknown
workflow subcommand: cancel" (cli.ts:478-484). Active cancellation is
only available via:
  - /workflow cancel <run-id> chat slash command (all platforms)
  - Cancel button on the Web UI dashboard
  - POST /api/workflows/runs/{runId}/cancel REST endpoint

cli-commands.md: removed the \`### archon workflow cancel <run-id>\`
subsection; kept the \`abandon\` subsection but made it explicit that
abandon does NOT kill a subprocess. Added a call-out box at the bottom
of the abandon section explaining where to go for actual cancellation.

troubleshooting.md "running forever" section: split the original
cancel-vs-abandon advice into three bullets — Web UI / CLI abandon (for
orphans, no subprocess kill) / chat \`/workflow cancel\` (for live runs
that need interruption). Added an explicit "there is no archon workflow
cancel CLI subcommand" parenthetical since the wrong command was being
suggested in flow.

I1: the \`archon workflow list --json\` diagnostic used an incorrect jq
filter. workflow list's --json output (workflow.ts:185-219) has shape
{ workflows: [{ name, description, provider?, model?, ... }], errors: [...] }
with no \`runs\` field — \`jq '.workflows[] | select(.runs)'\` returns empty
unconditionally. Replaced with \`archon workflow status --json | jq '.runs[]'\`,
which matches the actual shape of workflowStatusCommand at
workflow.ts:852+ ({ runs: WorkflowRun[] }). Also tightened the narration
to distinguish JSON from human-readable status output.

No change to the commit history in this PR — these are follow-up fixes
to claims I introduced in earlier commits of this branch (f10b989e for
C1, 66d2b86e for I1).

* fix(skill): remove env-leak gate references (feature was removed in provider extraction)

C2 from the PR code-reviewer (comment 4311243858). The pre-spawn env-leak
gate was removed from the codebase during the provider-extraction refactor
— see TODO(#1135) at packages/providers/src/claude/provider.ts:908. Zero
hits for --allow-env-keys / allowEnvKeys / allow_env_keys / allow_target_repo_keys
across packages/. The CLI's parseArgs (cli.ts:182-208) has no
--allow-env-keys option, and because parseArgs uses strict: false, an
unknown --allow-env-keys would be silently ignored rather than error.

What remains accurate and is NOT touched:
- Three-Path Env Model section (user/repo archon-owned envs are loaded;
  target repo <cwd>/.env keys are stripped from process.env at boot)
  still correctly describes current behavior, grounded in
  packages/paths/src/strip-cwd-env.ts + env-integration.test.ts
- Per-Project Env Injection section (Option 1: .archon/config.yaml env:
  block; Option 2: Web UI Settings → Projects → Env Vars) is unchanged —
  both remain the sanctioned way to get env vars into subprocesses

Removed claims (all three files):
- cli-commands.md: --allow-env-keys flag row in the workflow run flags
  table
- repo-init.md: the "Env-leak gate" subsection at the end of Per-Project
  Env Injection listing 5 remediations (all of which reference UI/CLI/
  config surfaces that don't exist). Replaced with a succinct callout
  that explains the actual current behavior — target repo .env keys are
  stripped, workflows that need those values should use managed
  injection — so the reader still gets the "where to put my env vars"
  answer
- troubleshooting.md: the "Cannot register: codebase has sensitive env
  keys" section (error message that can no longer be emitted)

If the env-leak gate is ever resurrected per TODO(#1135), the docs can be
re-added then. The CHANGELOG v0.3.0 entry describing the gate is a
historical record of past behavior and does not need to be rewritten.

* fix(skill/troubleshooting): correct JSONL event type names and field name

C3 from the PR code-reviewer (comment 4311243858). The troubleshooting
reference's event-types table used _started / _completed / _failed
suffixes, but packages/workflows/src/logger.ts:19-30 shows the actual
WorkflowEvent.type enum is:

  workflow_start | workflow_complete | workflow_error |
  assistant | tool | validation |
  node_start | node_complete | node_skipped | node_error

The second jq recipe also queried `.event` but the discriminator is `.type`.

Fixes:
- Event table: renamed columns (_started → _start, _completed → _complete,
  _failed → _error). Explicitly called out the field name as `type` so the
  reader knows what jq selector to use
- Replaced the "tool_use / tool_result" row with a single `tool` row and
  listed its actual payload fields (tool_name, tool_input, duration_ms,
  tokens) — tool_use/tool_result are SDK message kinds that appear within
  the AI stream, not top-level log event types
- Added a `validation` row (was missing; it's emitted by workflow-level
  validation calls with `check` and `result` fields)
- Removed `retry_attempt` row — this event type is not emitted to the
  JSONL file. Retry bookkeeping goes through pino logs, not the workflow
  log file
- Added an explicit callout that loop_iteration_started /
  loop_iteration_completed (and other emitter-only events) go through
  the workflow event emitter + DB workflow_events table, NOT the JSONL
  file. Pointed readers to the DB or Web UI for loop-level detail. This
  distinguishes the two parallel event systems — easy to conflate
  (store.ts:11-17 uses _started/_completed/_failed for the DB side,
  logger.ts uses _start/_complete/_error for JSONL)
- Fixed the "all failed events" jq recipe: .event → .type and _failed → _error
- Minor cleanup: the inline "tool_use events" mention in the "running
  forever" section said the wrong event name — updated to "tool or
  assistant events in the tail"

Grounded in packages/workflows/src/logger.ts (canonical JSONL event
shape) and packages/workflows/src/store.ts (the parallel DB event
naming, which the reviewer correctly flagged as different and worth
keeping distinct).

* fix(skill): two stragglers from the code-reviewer audit

Cleanup of two references that slipped through the earlier C1 and C3 fixes:

- references/troubleshooting.md:126: \`node_failed\` → \`node_error\`
  (the "Node output is empty" diagnostics section references the JSONL
  log, which uses the logger.ts enum — not the DB workflow_events table
  which does use \`node_failed\`). The C3 fix corrected the event table
  and one jq recipe but missed this inline mention.

- references/interactive-workflows.md:106: removed \`archon workflow
  cancel <run-id>\` (nonexistent CLI subcommand) from the
  troubleshooting bullet. This was pre-existing before the hardening
  PR but fell within the C1 remediation scope. Replaced with the
  correct triage: reject (approval gate only) vs abandon (orphan
  cleanup, no subprocess kill) vs chat /workflow cancel (actual
  subprocess termination).

Grounded in the same sources as the earlier C1/C3 commits:
packages/cli/src/cli.ts:318-485 (no cancel case) and
packages/workflows/src/logger.ts:19-30 (JSONL type enum).

* feat(skill): point to archon.diy as the canonical docs source

The skill had no reference to archon.diy (the live docs site built from
packages/docs-web/). Several reference files said "see the docs site"
without naming the URL, leaving the agent to guess or grep the repo for
the hostname. An agent with the skill loaded should know that when the
distilled reference pages don't cover a case, the full canonical docs
are one WebFetch away.

SKILL.md: new "Richer Context: archon.diy" section between Routing and
Running Workflows. Covers:
- When to reach for the live docs (longer examples, tutorial framing,
  features the skill only mentions in passing, "where's that
  documented?" user questions)
- URL map — 13 starting points covering getting-started, book (tutorial
  series), guides/ (authoring + per-node-type + per-node-feature),
  reference/ (variables, CLI, security, architecture, configuration,
  troubleshooting), adapters/, deployment/
- Precedence: skill refs first (context-cheap, tuned for agents), docs
  site as escalation. Prevents agents defaulting to WebFetch when a
  local skill ref already covers the answer

Also upgrades the 5 existing generic "docs site" mentions across
reference files to concrete archon.diy URLs with anchor fragments where
helpful:
- good-practices.md: Inline sub-agents pattern → archon.diy/guides/
  authoring-workflows/#inline-sub-agents
- troubleshooting.md: "Install page on the docs site" → archon.diy/
  getting-started/installation/
- workflow-dag.md: "Workflow Description Best Practices" → anchor link;
  sandbox schema reference → archon.diy/guides/authoring-workflows/
  #claude-sdk-advanced-options
- repo-init.md: Security Model reference → archon.diy/reference/
  security/#target-repo-env-isolation (deep-link into the section that
  covers the <cwd>/.env strip behavior)

URL source of truth: astro.config.mjs:5 (site: 'https://archon.diy').
URL structure mirrors packages/docs-web/src/content/docs/<section>/
<page>.md — verified by the 62 pages the docs build produces.

* chore(workflows): switch default Opus pin to opus[1m] alias (#1395)

Anthropic's Opus 4.7 landed 2026-04-16; on the Anthropic API, opus /
opus[1m] now resolve to 4.7 with a 1M context window at standard
pricing. Using the alias instead of the hard-pinned claude-opus-4-6[1m]
lets bundled default workflows auto-track the recommended Opus version.

No explicit effort is set, so nodes inherit the per-model default
(xhigh on 4.7, high on 4.6).

* fix(workflow): migrate piv-loop plan handoff to $ARTIFACTS_DIR (#1398)

* fix(workflow): migrate piv-loop plan handoff to $ARTIFACTS_DIR (#1380)

The create-plan node used a relative path (.claude/archon/plans/{slug}.plan.md)
that the AI agent would sometimes write to a different location, breaking all
downstream nodes that glob for the plan file. Migrated all plan/progress file
references to $ARTIFACTS_DIR/plan.md and $ARTIFACTS_DIR/progress.txt, matching
the pattern used by archon-fix-github-issue and other workflows.

Changes:
- Replace slug-based plan path with $ARTIFACTS_DIR/plan.md in create-plan node
- Replace ls -t glob discovery with direct $ARTIFACTS_DIR/plan.md reads in
  refine-plan, code-review, and fix-feedback nodes
- Replace empty-string guard with file-existence check in implement-setup bash
- Migrate progress.txt references in implement loop to $ARTIFACTS_DIR/
- Add explicit plan/progress paths in finalize node
- Regenerated bundled-defaults.generated.ts

Fixes #1380

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

* fix(workflow): address review findings in archon-piv-loop

- Rename 'Step 2: Write the Plan' to 'Step 2: Plan File Location' to
  eliminate the duplicate heading that collided with Step 3's identical
  title in the create-plan node
- Guard implement-setup against a 0-task plan file: exit 1 with a
  clear error when no '### Task N:' sections are found, preventing a
  silent no-op implement loop
- Remove 2>/dev/null from code-review commit so pre-commit hook failures
  and other stderr are visible to the agent instead of silently swallowed
- Replace '|| true' on git push in finalize with an explicit WARNING echo
  so push failures (auth, upstream conflict, no remote) surface to the
  agent rather than being silently ignored
- Regenerate bundled-defaults.generated.ts

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

* chore(workflows): regenerate bundled defaults to match opus[1m] alias

The bundle was stale relative to the YAML sources after #1395 merged —
check:bundled was failing CI. Regenerated; no YAML edits.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

* test(workflows): add anyFailed status derivation coverage for DAG executor (#1403)

PIV Task 1: Adds three new tests in a dedicated describe block
'executeDagWorkflow -- final status derivation' covering the anyFailed
branch (dag-executor.ts ~line 2956) that previously had no direct test:
- one success + one independent failure calls failWorkflowRun (not completeWorkflowRun)
- multiple successes + one failure calls failWorkflowRun (not completeWorkflowRun)
- trigger_rule: none_failed skips dependent node but anyFailed still marks run failed

Fixes #1381.

* docs/skill: add parameter-matrix.md quick-lookup reference

New reference for the archon skill: a single-glance lookup of which
parameter works on which node type, an intent-based "how do I..." table,
a consolidated silent-failure catalog, and an inline agents: section
(previously only referenced via archon.diy).

Purpose is complementary, not duplicative:
- workflow-dag.md remains the authoring guide
- dag-advanced.md remains the hooks/MCP/skills/retry deep-dive
- good-practices.md remains the patterns and anti-patterns
- parameter-matrix.md is the grep-this-first lookup when you know the
  outcome you want but not which field gets you there

Also registers the new reference in SKILL.md routing table.

* docs: point contributors at PR template and Closes #N convention

Add explicit references to .github/PULL_REQUEST_TEMPLATE.md in both
CONTRIBUTING.md and CLAUDE.md, plus a reminder to link issues with
Closes/Fixes/Resolves so they auto-close on merge. Repo-triage runs
were flagging dozens of partially-filled or unlinked PRs each cycle.

* feat(workflows): add maintainer-standup workflow for daily PR/issue triage (#1428)

* feat(workflows): add maintainer-standup workflow for daily PR/issue triage

Daily morning briefing that pulls origin/dev, triages all open PRs and assigned
issues against direction.md, and surfaces progress vs. the previous run. Designed
for live-checkout use (worktree.enabled: false) so it can read its own state.

Layout under .archon/maintainer-standup/:
  - direction.md (committed) — project north-star: what Archon IS / IS NOT.
    Drives PR P4 polite-decline classification with cited clauses.
  - README.md / profile.md.example — setup docs and template for new maintainers.
  - profile.md, state.json, briefs/YYYY-MM-DD.md — gitignored, per-maintainer.

Engine:
  - 3 parallel gather scripts in .archon/scripts/maintainer-standup-*.ts
    (git-status, gh-data, read-context) — bun runtime, JSON stdout.
  - Synthesis node: command file with output_format schema for
    { brief_markdown, next_state }.
  - Persist node: tiny inline bun script writes both to disk.

Run-to-run continuity: state.json carries observed_prs/issues snapshots, so the
next run can detect what merged, what closed, what the maintainer shipped, and
which carry-over items aged past N days.

Also adds .archon/** to the ESLint global ignore list (matches the existing
.claude/skills/** pattern) since .archon/ is user content and not part of any
tsconfig project.

* fix(maintainer-standup): address CodeRabbit review on #1428

- gh-data: bump --limit 100 → 1000 on all_open_prs and warn loudly when
  the cap is hit; preserves the observed_prs invariant the next-run
  "resolved since last run" diff depends on. (CodeRabbit critical)
- maintainer-standup.md: clarify P1 CI signal — the gathered payload only
  carries mergeStateStatus, not statusCheckRollup; for borderline P1s,
  drill in via `gh pr checks <n>`. (CodeRabbit minor)
- workflow.yaml persist: write briefs under local YYYY-MM-DD (sv-SE
  locale) instead of UTC ISO date, so an evening run doesn't file
  tomorrow's brief and break recent_briefs lookups. (CodeRabbit minor)
- workflow.yaml persist: wrap state/brief writes in try/catch; on
  failure dump brief_markdown and next_state to stderr so a 5-minute
  Sonnet synthesis isn't lost to a transient disk error. (CodeRabbit minor)
- gh-data + git-status: switch from execSync (shell-string) to
  execFileSync (argv array) for git/gh invocations. Defense-in-depth
  against shell metacharacters in values that pass through (esp. the
  gh_handle from profile.md). (CodeRabbit nitpick)

* feat(workflows): support explicit tags in workflow YAML (#1190)

Add optional `tags: string[]` to `workflowBaseSchema`. Explicit values take precedence over keyword inference; `tags: []` suppresses inference end-to-end; omitting the field falls back to inference (backwards compatible). Non-array values warn-and-ignore matching the sibling `worktree`/`additionalDirectories` patterns.

* feat(workflows): add maintainer-review-pr and group maintainer workflows under maintainer/ (#1430)

* feat(workflows): add maintainer-review-pr and group maintainer workflows under .archon/workflows/maintainer/

Adds the maintainer-review-pr workflow — a Pi/Minimax-based PR triage
flow that gates on direction alignment, scope focus, and PR-template
quality before doing any deep review. If the gate clears, runs the
five review aspects (code/error-handling/test-coverage/comment-quality/
docs-impact) as parallel Archon nodes and auto-posts a synthesized
review comment. If the gate fails (direction conflict, multiple
concerns, sprawling scope), drafts a polite-decline comment and pauses
for the maintainer's approval before posting.

Reorganizes the existing maintainer-standup workflow into the same
subfolder so all maintainer-facing workflows live together. Subfolder
grouping is supported by the workflow loader (1 level deep, resolution
by filename).

What lands:

- .archon/workflows/maintainer/maintainer-standup.yaml (moved from
  .archon/workflows/maintainer-standup.yaml)
- .archon/workflows/maintainer/maintainer-review-pr.yaml (new)
- .archon/commands/maintainer-review-{gate,code-review,error-handling,
  test-coverage,comment-quality,docs-impact,synthesize,report}.md (new,
  Pi-tuned variants of the existing review-agent commands so they avoid
  Claude-only Task / sub-agent patterns)

Pi/Minimax integration:

- Uses provider: pi, model: minimax/MiniMax-M2.7 — verified via the
  e2e-minimax-smoke test that Pi correctly routes to Minimax (session
  jsonl confirms provider=minimax) and that Pi's best-effort
  output_format parser handles the gate's nested schema.
- Two test runs landed real comments: a direction-decline on PR #1335
  and a deep-review on PR #1369. Both were posted to GitHub via the
  workflow's gh pr comment node.

* chore(workflows): also group repo-triage under .archon/workflows/maintainer/

repo-triage is the third maintainer-facing workflow alongside maintainer-standup and maintainer-review-pr; group it in the same subfolder for consistency. Subfolder resolution is by filename so the workflow name is unchanged.

* feat(pi): use ModelRegistry to support custom models and skip auth for unmapped providers (#1284)

Closes #1096.

- Switch Pi provider model lookup from pi-ai's getModel() (static catalog
  only) to ModelRegistry.create(authStorage).find() so user-configured
  custom models in ~/.pi/agent/models.json (LM Studio, ollama, llamacpp,
  custom OpenAI-compatible endpoints) are discoverable.
- Remove the local lookupPiModel helper.
- For env-var-mapped providers (anthropic, openai, etc.) still throw
  with a pi /login hint when credentials are missing. For unmapped
  providers, log pi.auth_missing at info and continue so local models
  that don't need credentials work without ceremony.
- Surface modelRegistry.getError() in the not-found message and emit
  pi.model_not_found so users debugging custom-provider configs see the
  real cause (e.g. missing baseUrl in models.json).
- Guard AuthStorage.create() and ModelRegistry.create() with try/catch
  so a malformed ~/.pi/agent/auth.json surfaces with Pi-framed context
  instead of a raw SDK stack trace.
- Document the credential-free path for local providers in ai-assistants.md.

Co-authored-by: Matt Chapman <Matt@NinjitsuWeb.com>

* chore(workflows): group smoke-test workflows under test-workflows/ + add e2e-minimax-smoke (#1431)

* chore(workflows): group all smoke-test workflows under .archon/workflows/test-workflows/

Move the 7 existing e2e-*.yaml smoke tests plus the new e2e-minimax-smoke
test into a dedicated subfolder. Subfolder grouping is supported by the
workflow loader (1 level deep, resolution by filename) so workflow names
are unchanged. Mirrors the .archon/workflows/maintainer/ split landing
in #1430.

Also adds e2e-minimax-smoke.yaml — a sanity check that Pi correctly
routes to Minimax M2.7 via the user's local pi auth, and that Pi's
best-effort output_format parser handles a small nested schema. Asserts
routing by reading the most recent Pi session jsonl rather than asking
the model to self-identify (LLMs are unreliable narrators about their
own identity, especially when Pi's system prompt mentions other
providers as defaults).

* fix(e2e-minimax-smoke): address CodeRabbit review on #1431

- Widen find window from -mmin -3 to -mmin -10. The smoke's three Pi
  nodes plus the assert can collectively run several minutes on slow
  networks; 3 minutes was tight enough to false-FAIL on a healthy run.
  (CodeRabbit minor)
- Drop non-deterministic `head -1` over `find` output. find doesn't
  guarantee any order; on a tie, the wrong file would be picked. Now
  iterates all matching sessions and breaks on first one carrying the
  routing signal — any match is sufficient evidence. (CodeRabbit minor)
- Replace single-regex `'"provider":"minimax".*"modelId":"MiniMax-M2.7"'`
  with two separate greps joined by `&&`. JSON field order isn't part of
  Pi's contract; a future Pi release reordering `provider` and `modelId`
  in the model_change event would silently false-FAIL the original
  pattern. The new check is order-independent. (CodeRabbit major)

* fix(maintainer-review): address CodeRabbit findings on #1430 (#1432)

Six findings, two majors and four minors/nitpicks:

- gate.md L17 vs L77: resolved conflicting input-source instructions.
  Body claimed "all inline, no extra fetch" while a later phase
  permitted reading PULL_REQUEST_TEMPLATE.md. Now: explicit "one
  allowed extra read" callout in Phase 1 + matching wording in Gate C.
  (CodeRabbit major)

- gate.md fenced blocks: added missing language identifiers (text/json/
  markdown) to satisfy markdownlint MD040. (CodeRabbit minor)

- gate.md L155 + read-context.ts: deterministic clock. The 3-day deadline
  was anchored to prior_state.last_run_at, which can be stale and produce
  past-dated deadlines. Moved both today and deadline_3d into the
  read-context.ts output (computed via sv-SE locale → ISO date in local
  time) and instructed the gate to use $read-context.output.deadline_3d
  directly. LLMs are unreliable at calendar arithmetic; this avoids it
  entirely. (CodeRabbit major)

- maintainer-review-pr.yaml fetch-diff: dropped 2>/dev/null on gh pr diff
  so auth / network / deleted-PR failures fail the node instead of
  feeding an empty diff to the gate. Empty-but-successful diff (PR has
  no changes) is now an explicit marker the gate can detect. (CodeRabbit
  minor)

- maintainer-review-pr.yaml approve-unclear: added capture_response: true
  so the maintainer's approve comment flows to the report node. Reject
  reasoning is already captured by Archon's run record. (CodeRabbit
  minor)

- maintainer-review-pr.yaml post-decline + report.md: the gh pr edit
  --add-label call previously swallowed all errors with || true and the
  report still claimed the label was applied. Now writes applied/skipped
  to $ARTIFACTS_DIR/.label-applied + the gh stderr to .label-error so
  the report can describe the actual outcome. (CodeRabbit nitpick)

* fix(workflows): approval gate bypass after reject-with-redraft on resume (#1435)

* fix(workflows): approval gate bypass after reject-with-redraft on resume

When an approval node was rejected with on_reject.prompt, the synthetic
PromptNode built to run the on_reject prompt reused the approval gate's
own node ID. executeNodeInternal then wrote a node_completed event with
that ID, causing getCompletedDagNodeOutputs to treat the gate as already
completed on the next resume — bypassing the human gate entirely.

Fix: give the synthetic node the ID `${node.id}:on_reject` so its
node_completed event has a distinct step_name that won't match the
approval gate slot in priorCompletedNodes.

Adds a regression test asserting no node_completed event with the
approval gate's ID is written during on_reject execution.

Fixes #1429

* test(workflows): add positive assertion and SSE side-effect comment for on_reject synthetic node

Add complementary positive assertion to the regression test to verify that
node_completed is written exactly once with step_name 'review:on_reject',
ensuring future refactors that suppress the event entirely would be caught.

Add inline comment in executeApprovalNode documenting the known SSE side-effect:
node_started/node_completed events with nodeId='review:on_reject' flow through
the SSE pipeline into the web UI, resulting in a transient phantom node in the
execution view. This is cosmetic-only — the human gate contract is preserved.

* simplify: reduce duplicate cast pattern in on_reject test assertions

* feat(workflows): add mutates_checkout to allow concurrent runs on live checkout (#1438)

* feat(workflows): add mutates_checkout field to skip path-lock for concurrent runs

Add `mutates_checkout: boolean` (optional, default true) to the workflow
schema. When set to false, the executor skips the path-exclusive lock
that serializes all runs on the same working path, allowing N concurrent
runs on the same live checkout.

The primary use case is `maintainer-review-pr`, which reads shared state
but writes only to per-run artifact paths and GitHub PR comments — two
parallel reviews of different PRs should not fail with "Workflow already
active on this path".

Changes:
- `schemas/workflow.ts`: add optional `mutates_checkout` field
- `loader.ts`: parse and propagate the field (warn-and-ignore on invalid values)
- `executor.ts`: wrap path-lock guard in `if (workflow.mutates_checkout !== false)`
- `executor.test.ts`: two new tests in the concurrent-run guard suite
- `maintainer-review-pr.yaml`: opt in with `mutates_checkout: false`

* test(workflows): add loader tests for mutates_checkout parsing

- Add 5 tests covering false, true, omitted, and invalid (string "yes") values
- Invalid non-boolean values are silently dropped with warn — now explicitly tested
- Remove the // end mutates_checkout guard trailing comment (no precedent in file)
- Clarify loader comment: "parse/warn pattern" not "warn-and-ignore pattern" to avoid implying the return style matches interactive

* simplify: collapse nodeType/aiFields pair into single nonAiNode object in parseDagNode

* docs: replace String.raw with direct assignment in script node examples (#1434)

* docs: replace String.raw with direct assignment in script node examples

String.raw`$nodeId.output` fails silently when substituted output contains
a backtick, terminating the template literal early and producing cryptic parse
errors. JSON is valid JS expression syntax, so direct assignment is safe for
all valid JSON values including those with backticks.

- Replace String.raw pattern in dag-workflow.yaml example
- Replace String.raw pattern in archon-workflow-builder.yaml template
- Add CAUTION bullet in workflow-dag.md Script Node section
- Add Silent Failures item #14 in parameter-matrix.md
- Add Starlight caution aside in script-nodes.md
- Extend script bodies bullet in variables.md
- Regenerate bundled-defaults.generated.ts

Fixes #1427

* docs: fix Rule 6 in generate-yaml prompt to distinguish bun vs uv patterns

Rule 6 still referenced JSON.parse after the example was updated to direct
assignment, creating a contradiction for the AI code generator. Update the
prose to explicitly distinguish TypeScript/bun (direct assignment) from
Python/uv (json.loads), matching the updated embedded example.

* chore(workflows): group experimental workflows under .archon/workflows/experimental/

Move two repo-scoped workflows that were sitting untracked at the workflow
root into a dedicated subfolder. Subfolder grouping is supported by the
loader (1 level deep, resolution by filename), so workflow names are
unchanged and the /release skill still resolves archon-release correctly.

Files moved:
- archon-fix-github-issue-experimental.yaml — Path-A variant of the
  issue-fix workflow used today to land #1434, #1435, #1438.
- archon-release.yaml — the live release workflow used by the /release
  skill end-to-end (validate -> binary smoke -> version bump -> changelog
  -> approval -> commit -> PR -> tag -> Homebrew formula update).

* fix(workflows): export ARTIFACTS_DIR, LOG_DIR, BASE_BRANCH to bash nodes (#1387)

executeBashNode previously only merged explicit envVars on top of
process.env. The three well-known workflow directories (artifactsDir,
logDir, baseBranch) were passed as function parameters and used for
compile-time substitution of $ARTIFACTS_DIR / $LOG_DIR / $BASE_BRANCH
in the script body, but were never added to the subprocess environment.

As a result, any script that relied on shell-runtime expansion — e.g.
JSON_FILE="${ARTIFACTS_DIR}/foo.output.json" inside a heredoc, an
inherited helper script, or a `bash -c` subshell — saw the variable
unset and silently fell back to its default (typically an empty string
or "."), writing artifacts to the workflow cwd instead of the nominal
artifacts directory.

Always build subprocessEnv from process.env plus the three well-known
directories, then allow explicit envVars to override. Compile-time
substitution behavior is unchanged; existing scripts that do not
reference these variables are unaffected; user-supplied envVars still
win on conflict.

* fix(workflow): substitute $nodeId.output refs in approval messages (#1426)

* fix(workflow): substitute \$nodeId.output refs in approval messages

Approval node messages were emitted as raw strings, bypassing the
substituteNodeOutputRefs() pass that prompt/bash/loop/cancel nodes
all run. This made interactive workflows like atlas-onboard show
literal "\$gather-context.output.repo_name" placeholders to humans
at HITL gates, leaving them unable to know what they were approving.

Fix: rendered the approval.message through substituteNodeOutputRefs
once at the top of the standard approval gate path, then used the
resolved string in all 4 emission sites (safeSendMessage,
createWorkflowEvent, pauseWorkflowRun, event-emitter).

Test: new dag-executor.test case wires a structured-output upstream
node into an approval node and asserts pauseWorkflowRun receives the
substituted message ("Repo: hcr-els | App: CCELS | Port: 3012")
rather than the literal placeholders.

Repro: any workflow with an approval node whose message references
\$nodeId.output[.field]. Observed in the wild on atlas-onboard's
confirm-context HITL gate.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* test(workflow): extend approval-substitution test to cover all 4 emission sites

Per CodeRabbit review: the original test only verified pauseWorkflowRun
received the substituted message, but the fix touches 4 emission sites.
A future regression at safeSendMessage / createWorkflowEvent / event-emitter
would silently leave the test passing while users still saw raw $node.output
placeholders.

Adds two additional assertions:
- platform.sendMessage prompt contains substituted message + does NOT
  contain literal $gather-context.output placeholders
- The persisted approval_requested workflow event's data.message is
  substituted

Event-emitter assertion deferred (no existing pattern for spying on the
global emitter in this test file). Two of three secondary surfaces
covered closes the practical regression risk — both are user-visible
(chat prompt + audit-log event); the emitter is internal only.

Test count: 7 pass / 22 expect() (was 18). Full suite 193 pass / 353
expect() — no regressions.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

* feat(workflows): expose $LOOP_PREV_OUTPUT in loop node prompts (#1286) (#1367)

* feat(workflows): expose $LOOP_PREV_OUTPUT in loop node prompts (#1286)

Adds a new substitution variable that carries the previous loop iteration's
cleaned output into the next iteration's prompt. Empty on iteration 1; the
prior iteration's output (after stripCompletionTags) on iteration 2+.

Why: fresh_context: true loops have no way to reference what the previous
pass produced or why it failed without dragging the full session forward.
$LOOP_PREV_OUTPUT closes that gap with zero session-cost — same trust
boundary as $nodeId.output, no new external surface.

Changes:
- packages/workflows/src/executor-shared.ts: substituteWorkflowVariables
  accepts a 10th positional loopPrevOutput arg and substitutes
  $LOOP_PREV_OUTPUT (defaults to '').
- packages/workflows/src/dag-executor.ts: executeLoopNode passes
  lastIterationOutput on iteration 2+ (and explicit '' on iteration 1 /
  the first iteration of an interactive resume, since lastIterationOutput
  is a per-call variable that does not survive resume metadata).
- Unit tests: 3 new cases in executor-shared.test.ts.
- Integration tests: 2 new cases in dag-executor.test.ts verifying the
  prompt sent to the AI on iter 1 vs iter 2, and that the value reflects
  cleaned output (no <promise> tags).
- Docs: variables.md, loop-nodes.md (new "Retry-on-failure" pattern),
  CLAUDE.md variable reference.

Backward compatibility: prompts that don't reference $LOOP_PREV_OUTPUT are
unaffected. All 843 workflow tests + type-check + lint + format:check +
bun run validate pass locally.

* docs: address coderabbit review on variables/loop-nodes

- variables.md: include $LOOP_PREV_OUTPUT in substitution-order list and
  availability table to match the new variable row at line 30
- loop-nodes.md: document the interactive-resume exception where the first
  iteration after an approval-gate resume still receives an empty
  $LOOP_PREV_OUTPUT regardless of iteration number (per dag-executor.ts
  L1781-1783 where i === startIteration always clears prev output)

* docs(changelog): add Unreleased entry for $LOOP_PREV_OUTPUT (#1367 review)

* test(loop): add resume-from-approval integration test for $LOOP_PREV_OUTPUT (#1367 review)

Per maintainer-review-pr suggestion (Wirasm): two-call integration test
covering the resume-from-approval scenario.

  - Call 1: fresh interactive loop pauses at the gate after iteration 1 and
    asserts $LOOP_PREV_OUTPUT substitutes to empty on iter 1 (no prior
    output) plus the gate pause is recorded.
  - Call 2: resumed run with metadata.approval populated. The first
    resumed iteration must substitute $LOOP_PREV_OUTPUT to '', NOT to the
    paused run's iter-1 output (which lived in a different process and is
    not persisted). $LOOP_USER_INPUT still flows through as normal.

Locks the documented invariant at dag-executor.ts:1769-1772.

---------

Co-authored-by: voidborne-d <DottyEstradalco@allergist.com>

* feat(maintainer-standup): surface contributor replies since last run (#1457)

The brief was missing a key signal — when contributors reply on PRs or
issues, the maintainer wouldn't see it explicitly. Empirically reviewed
PR replies were buried under aggregate updatedAt timestamps with no
indication of WHO replied or WHAT they said.

This adds a new "Replies waiting on you" section to the daily brief,
sourced from two paginated GitHub API calls scoped by since=last_run_at:

  - /repos/{o}/{r}/issues/comments  PR + issue conversation comments
  - /repos/{o}/{r}/pulls/comments   inline code-review comments

Filters applied:
  - Skip the maintainer's own comments (gh_handle from profile.md)
  - Skip GitHub bot accounts (login ending in [bot]) — coderabbitai,
    chatgpt-codex-connector, dependabot, etc. They post a constant
    churn of automated review tooling that drowns out human replies;
    the maintainer wants the latter.

Output is grouped by PR/issue number with kind classification:
  - issue              comment on a non-PR issue
  - pr_conversation    PR conversation-level comment
  - pr_review          inline code-review comment (most actionable —
                       usually needs a code-level response, so kind
                       upgrades to pr_review whenever review comments
                       arrive on a PR that also has conversation ones)

Sorted by recency (newest reply first). Synthesizer reads
gh-data.output.replies_since_last_run and renders a section.

Verified on a backdated state.json (last_run_at = yesterday morning):
22 human replies on 22 PRs/issues, bot noise filtered (32 → 22 after
the [bot] filter). Surfaces …
Adds the Archon Studio visual builder (beta) at /console/builder: a controlled React Flow canvas with node palette, per-node inspector, inline validation panel, read-only YAML preview, smart-guide snapping, marquee select, and a right-click context menu. Pure DOM-free editor kernels (state/history/clipboard/align/smart-guides/serialize) with ~290 bun:test units. Fixture-backed and experiment-folder-only — zero net-new web dependencies; load/save lands in PR-3.

Part of coleam00#1863 (PR 2 of 3).
…y (reverts coleam00#1923) (coleam00#2046)

Reverts coleam00#1923 so interactive loops re-thread the stored gate session on the first post-gate iteration, restoring cross-gate conversation continuity. Closes coleam00#2004. Takeover of coleam00#2005.

Co-authored-by: ianstantiate <251394470+ianstantiate@users.noreply.github.com>
PR-3 of the Archon Studio integration. Replaces the fixture-backed builder
route with a connected route that loads, edits, creates, renames, and deletes
real workflow YAML through the existing workflow CRUD endpoints (no server
changes).

- BuilderConnected at /console/builder[/:name]: project picker (per-cwd
  discovery, persisted + ?project= deep-link), workflow open/New/Rename/Delete,
  explicit Save with a dirty indicator and beforeunload + confirm nav guard
- skills/workflows.ts: loadWorkflow/saveWorkflow/deleteWorkflow/validateWorkflow
  verbs + pure buildWorkflowPath/buildSavePath helpers
- connect/save-logic.ts: pure serverErrorToIssues/serverValidationToIssues/
  blockingErrors/planRename/isValidWorkflowName (mirrors server isValidCommandName)
- BuilderPage gains an additive extraIssues prop; import + server issues merge
  into the existing IssueList
- bundled workflows open read-only, Save-as writes a project override; filename
  (:name) and in-YAML name: stay in sync
- HttpError exposes bodySnippet; K.workflow(cwd,name) cache key
- 19 new unit tests (save-logic, workflows path builders)

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@seanrobertwright seanrobertwright force-pushed the feat/studio-builder-pr3-connected-mode branch from af0ba60 to 835f596 Compare June 30, 2026 18:41
@seanrobertwright

Copy link
Copy Markdown
Owner Author

Superseded by the upstream PR now that PR-2 (coleam00#2015) is merged into coleam00/Archon:dev. PR-3 has been rebased onto upstream/dev (contains only the single PR-3 commit) and opened upstream: coleam00#2051. Closing this fork-internal draft.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants