@aperant/framework 0.17.0 → 0.20.0

package/skills/apt-plan/SKILL.md

@@ -504,13 +504,13 @@ node packages/framework/bin/apt-tools.mjs commit "plan: create implementation pl
 ## 8a. Runtime-context adapters
 
 If `APERANT_TERMINAL_ID` is set (you are running under the Aperant
-Conductor — a master-orchestrator agent inside the Aperant app), see
-`adapters/conductor.md` for the plan-review handshake convention
-(`proceed` / `abort` / `[Conductor realignment]` stdin strings) the
-Conductor's drawer uses post-commit. The `artifact.ready{kind:'plan'}`
+Showrunner — a master-orchestrator agent inside the Aperant app), see
+`adapters/showrunner.md` for the plan-review handshake convention
+(`proceed` / `abort` / `[Showrunner realignment]` stdin strings) the
+Showrunner's drawer uses post-commit. The `artifact.ready{kind:'plan'}`
 signal itself is now emitted automatically by the `apt-tools commit`
 postcondition — no manual emit step required. Native invocations
-(Claude Code, Gemini, OpenCode, Codex with no Conductor context) can
+(Claude Code, Gemini, OpenCode, Codex with no Showrunner context) can
 skip the adapter entirely and proceed to Section 9.
 
 ## 9. Report

package/skills/apt-plan/adapters/{conductor.md → showrunner.md}

@@ -1,23 +1,23 @@
-# apt-plan adapter — Aperant Conductor
+# apt-plan adapter — Aperant Showrunner
 
 This adapter is **only loaded** when the planner runs under the Aperant
-Conductor (a master-orchestrator agent inside the Aperant desktop / web
+Showrunner (a master-orchestrator agent inside the Aperant desktop / web
 app). Native invocations of `/apt:plan` (from plain Claude Code, Gemini
 CLI, OpenCode, or Codex) IGNORE this file entirely — the framework
 behavior in `SKILL.md` is the source of truth for them.
 
 ## When to load this adapter
 
-Detect Conductor context by env var:
+Detect Showrunner context by env var:
 
 ```bash
 [ -n "$APERANT_TERMINAL_ID" ]
 ```
 
-The Conductor injects `APERANT_TERMINAL_ID` into every PTY it spawns.
-If the var is unset, you are NOT under the Conductor — stop reading.
+The Showrunner injects `APERANT_TERMINAL_ID` into every PTY it spawns.
+If the var is unset, you are NOT under the Showrunner — stop reading.
 
-## What changes under the Conductor
+## What changes under the Showrunner
 
 The planner's filesystem outputs (`spec.md`, `implementation_plan.json`)
 are unchanged. The ADDITION is one extra step after Section 8 (Persist
@@ -34,7 +34,7 @@ node packages/framework/bin/apt-tools.mjs commit "plan: ..." \
   --files spec.md implementation_plan.json
 ```
 
-…and the process is running under a Conductor PTY (env
+…and the process is running under a Showrunner PTY (env
 `APERANT_TERMINAL_ID` is set), `apt-tools commit` auto-emits a fully-
 formed `artifact.ready` envelope to `.aperant/events/{today}.jsonl`.
 The envelope carries the `task_id`, plan path, sha256 hash, and the
@@ -47,35 +47,35 @@ framework postcondition makes it work uniformly across QUICK, STANDARD,
 DEEP, and COMPLEX without violating the Fast Path Guarantee.
 
 **Planner authors don't need to do anything.** As long as you call
-`apt-tools commit` to land your plan artifacts, the Conductor will
+`apt-tools commit` to land your plan artifacts, the Showrunner will
 see `artifact.ready` and the drawer's PlanReadyCard will auto-promote.
 
 If the planner does NOT use `apt-tools commit` (it lands the plan via
 raw `git commit` or `git add`), the auto-emit will not fire. In that
-case the Conductor falls back to filesystem polling of the task dir
+case the Showrunner falls back to filesystem polling of the task dir
 (slightly higher latency, same outcome).
 
-### Plan-review handshake (Step 6 + 7 of Conductor v2)
+### Plan-review handshake (Step 6 + 7 of Showrunner v2)
 
 After emitting `artifact.ready{kind:'plan'}` the planner SHOULD pause at
-an idle prompt and listen for ONE of three Conductor-driven inputs:
+an idle prompt and listen for ONE of three Showrunner-driven inputs:
 
 - `proceed\r` — the human (via the PlanReadyCard's **Approve** button)
   approves the plan. Continue to `/apt:execute` as you would in the
   normal flow.
 - `abort\r` — the human rejected. Abandon this plan; do not start
   execution. Optionally exit the session cleanly.
-- `[Conductor realignment] <note>\r` — the human pressed **Realign**.
+- `[Showrunner realignment] <note>\r` — the human pressed **Realign**.
   Treat the `<note>` as additional planning context: re-open spec.md /
   implementation_plan.json, address the note's gaps, commit a new
   revision, and emit a fresh `artifact.ready{kind:'plan'}` (with the
   same task_id but a NEW request_id — the drawer keys cards on
   request_id, so re-using it would suppress the new card). The
-  realignment loop can repeat; after attempt_n >= 3 the Conductor may
+  realignment loop can repeat; after attempt_n >= 3 the Showrunner may
   decide to respawn the terminal entirely.
 
-These exact strings are pinned by the Conductor's `ConductorContextHost`
-handlers (`packages/ui/src/sections/conductor/ConductorContextHost.tsx`).
+These exact strings are pinned by the Showrunner's `ShowrunnerContextHost`
+handlers (`packages/ui/src/sections/showrunner/ShowrunnerContextHost.tsx`).
 Native CLI invocations of `/apt:plan` (no `APERANT_TERMINAL_ID`) skip
 this handshake and follow the normal report → `/apt:execute` flow.
 
@@ -84,7 +84,7 @@ this handshake and follow the normal report → `/apt:execute` flow.
 The Aperant Framework is consumed by multiple CLIs (Claude Code, Gemini,
 OpenCode, Codex) and by the Aperant app itself. The vast majority of
 `/apt:plan` invocations come from native CLIs — those should not see
-or execute Conductor-specific machinery. By isolating the Conductor's
+or execute Showrunner-specific machinery. By isolating the Showrunner's
 event-emit obligations to this adapter, the public skill stays minimal
 and the framework remains CLI-agnostic. The pattern mirrors
 `appendices/` (reasoning-stance loaders) but with a different semantic: