session-orchestrator 3.19.0 → 3.21.0

package/skills/discovery/probes-infra.md

@@ -10,10 +10,10 @@
 
 ```bash
 # GitLab: query recent pipeline status
-glab pipeline list --per-page 10
+glab pipeline list -R <OWNER>/<REPO> --per-page 10
 
 # GitHub: query recent workflow runs
-gh run list --limit 10
+gh run list -R <OWNER>/<REPO> --limit 10
 
 # Parse output for:
 # - Repeated failures (same pipeline failing 3+ times in a row)

package/skills/discovery/probes-session.md

@@ -55,9 +55,9 @@ Grep pattern: <claimed_addition>
 git show <commit_hash> -- <relevant_files>
 
 # "Closes #N" -> verify acceptance criteria from issue #N are met
-gh issue view <N> --json body -q '.body'
+gh issue view -R <OWNER>/<REPO> <N> --json body -q '.body'
 # or
-glab issue view <N>
+glab issue view -R <OWNER>/<REPO> <N>
 
 # Step 3: Cross-reference claims against actual changes
 git diff <commit_hash>~1..<commit_hash>
@@ -83,10 +83,10 @@ Evidence: <what was found or not found>
 
 ```bash
 # GitLab: list open issues sorted by last update
-glab issue list --per-page 100 | head -50
+glab issue list -R <OWNER>/<REPO> --per-page 100 | head -50
 
 # GitHub: list open issues sorted by last update
-gh issue list --limit 100 --json number,title,labels,updatedAt,assignees --jq '.[] | select(.updatedAt < "<30_days_ago_iso>")'
+gh issue list -R <OWNER>/<REPO> --limit 100 --json number,title,labels,updatedAt,assignees --jq '.[] | select(.updatedAt < "<30_days_ago_iso>")'
 
 # Flag:
 # - Issues with no activity in stale-issue-days (default: 30 days)
@@ -131,7 +131,7 @@ for issue in issues:
 "
 
 # GitHub: fetch issue bodies and parse cross-references
-gh issue list --limit 100 --json number,body --jq '.[] | {number, body}' | python3 -c "
+gh issue list -R <OWNER>/<REPO> --limit 100 --json number,body --jq '.[] | {number, body}' | python3 -c "
 import json, sys, re
 for line in sys.stdin:
     issue = json.loads(line)

package/skills/dispatcher/SKILL.md

@@ -1,6 +1,15 @@
 ---
 name: dispatcher
-description: Use when you want the orchestrator to pick the next repo to work on across your whole portfolio — it enumerates candidate repos below the confinement root, resolves free/busy from each repo's session.lock lease, ranks the FREE ones by backlog priority × staleness × readiness, recommends the single most worthwhile one via AskUserQuestion, atomically claims it, and routes you to the chosen entry command. Triggers: "what should I work on next", "dispatch me to a repo", "pick the next project", "run /dispatcher". <example>Context: operator finished a session and wants the next-best repo across the portfolio. user: "/dispatcher" assistant: "Ranked 18 free repos — top recommendation: Pencil-Designs (score 4.50, 90d stale). Confirm via the picker, I'll claim its lease atomically, then route you to /session deep."</example>
+description: >
+  Use when you want the orchestrator to pick the next repo to work on across your whole portfolio — it
+  enumerates candidate repos below the confinement root, resolves free/busy from each repo's session.lock
+  lease, ranks the FREE ones by backlog priority × staleness × readiness, recommends the single most
+  worthwhile one via AskUserQuestion, atomically claims it, and routes you to the chosen entry command.
+  Triggers: "what should I work on next", "dispatch me to a repo", "pick the next project", "run
+  /dispatcher". <example>Context: operator finished a session and wants the next-best repo across the
+  portfolio. user: "/dispatcher" assistant: "Ranked 18 free repos — top recommendation: Pencil-Designs
+  (score 4.50, 90d stale). Confirm via the picker, I'll claim its lease atomically, then route you to
+  /session deep."</example>
 model: sonnet
 ---
 

package/skills/evolve/SKILL.md

@@ -211,6 +211,34 @@ For each extracted pattern, check if a learning with same `type` + `subject` alr
 - **If exists:** propose confidence update (+0.15 if confirmed by new evidence, -0.2 if contradicted)
 - **If new:** propose as new learning with confidence 0.5
 
+This match is **exact string equality on `type` + `subject`** — it is blind to two records that say the same thing in different words, and it cannot detect a contradiction at all. The `-0.2 if contradicted` branch above has therefore had no producer since it was written. Step 3.3b is that producer.
+
+### Step 3.3b: Relation Judgment (#1016)
+
+> **Cadence: once per candidate.** Step 3.2b's zero-patterns check and Step 3.4's single AUQ are once-per-run; Step 3.5's write is once-per-run. This step is the only per-candidate one in Phase 3 — the pool build happens once, the judgment runs for each pattern that seeds a pool.
+
+> **Runs in `/evolve`, never in a wave.** The pool build is O(N²) over the candidate + corpus union (~13 ms at N=100 records; the viability boundary is ~N=2000). `/evolve` is operator-invoked and off the dispatch hot path — that is the whole reason this lives here and not in `skills/wave-executor/`. Do not invoke it from a wave prompt, an inter-wave checkpoint, or a hook.
+
+Skip this step entirely when `.orchestrator/metrics/learnings.jsonl` is absent or holds fewer than 2 entries — with no corpus there is no relation to judge.
+
+1. **Pool.** Call `buildCandidatePools(records, { now })` from `scripts/lib/learnings/candidates.mjs`, passing the union of this run's extracted candidates and the on-disk corpus. It returns `{pools, duplicates, stats}`: `duplicates` are the exact-`learning_key` groups (already certain — no judgment needed), and each `pools[]` entry is `{seed, candidates}` where `candidates[].record` is a bounded, per-seed, non-transitive neighbour set. No clustering, no transitive closure: a neighbour of a neighbour is not a neighbour.
+
+2. **Judge, per candidate that seeds a pool.** `buildJudgmentInput({candidate, neighbours})` then `judgeCandidate(input, { judge })`, both from `scripts/lib/learnings/judgment.mjs`. `buildJudgmentInput` returns `null` for a candidate with no usable `id` — skip that candidate, do not judge it. `judge` is the injected verdict provider: on Claude Code the coordinator reads the `input` envelope and returns the JSON object its `output_contract` field describes. There is no subagent type for this — do not dispatch one (#614: a read-only agent that must write its own sidecar never fires).
+
+3. **Apply, through the one choke point.** `applyVerdict(verdict, effects)` is the only place a judgment may become an effect. In `/evolve` every effect handler is a *proposal recorder*, never a writer: `refine` / `supersede` / `merge` record a proposed change, and `proposeContradiction` records a contradiction pair. `applyVerdict` resolves all four handlers before invoking any of them, so an unwired handler refuses the whole batch rather than applying the decisions that happened to come first.
+
+4. **Fail closed.** `verdict.ok === false` (any of the eight failure modes — unparseable, partial, phantom_id, self_reference, empty, timeout, enum_violation, duplicate_target) means **no relation was read**, not "no relation exists". The candidate keeps its Step 3.3 exact-match verdict and nothing about it is surfaced as a relation. Never fall back to a default decision, never repair-retry a malformed verdict, and never render an unreadable judgment to the operator — surfacing a relation IS the claim, so a voided judgment must not reach the AUQ at all.
+
+5. **Route into the existing gate.** Every surviving decision becomes an OPTION in Step 3.4's AskUserQuestion, never an action:
+   - `contradict` → a contradiction pair, presented as its own category beside "duplicate". If the operator selects it, it feeds the `-0.2 if contradicted` branch in Step 3.3 above, applied by Step 3.5(3) — which deliberately does NOT reset `expires_at`.
+   - `supersede` / `merge` → an omit-the-loser (or replace-both-with-one) proposal. If selected, the operator's next generation simply omits those ids and Step 3.5(5) archives them — never a hand-delete. The merged record must carry both sources' provenance in its own `evidence`.
+   - `refine` → an edit proposal against the existing record's `insight` / `evidence`.
+   - `skip` / `abstain` → nothing is surfaced.
+
+**The brandmauer holds here, unchanged (#693 FA2/FA3).** The judgment computes; it never writes. Every `.claude/rules/` write and every `learnings.jsonl` write stays behind the operator's Step 3.4 selection and Step 3.5's `--prune` invocation.
+
+**Named ceiling (revisit trigger).** A `supersede` or `merge` executed through Step 3.5(5) is tagged `_archive_reason: "superseded"` with a `_superseded_by` tombstone **only when the two records share `type` + non-empty `subject`** — that is `pruneLearnings()`'s own consolidation pass. A cross-wording pair (the exact case this step exists to find) does not share a subject, so its loser is archived `pruned` instead: still in the corpus, still resolvable by id, but the archive record does not name its replacement. Revisit when the CLI grows per-record drop routing, or when an archive audit needs to answer "what replaced this?" for cross-wording merges.
+
 ### Step 3.4: Present Findings via AskUserQuestion
 
 Present extracted patterns to the user for confirmation. Use AskUserQuestion with `multiSelect: true`:
@@ -244,7 +272,7 @@ If user selects "Skip all" or selects nothing, abort gracefully: "No learnings s
 
 For confirmed learnings, use atomic rewrite strategy:
 
-1. Read ALL existing lines from `.orchestrator/metrics/learnings.jsonl` (if exists) into memory. If not found, check `<state-dir>/metrics/learnings.jsonl` as a legacy fallback. If legacy data is found, it will be migrated to the v2 path on write (step 8).
+1. Read ALL existing lines from `.orchestrator/metrics/learnings.jsonl` (if exists) into memory. If not found, check `<state-dir>/metrics/learnings.jsonl` as a legacy fallback. If legacy data is found, it will be migrated to the v2 path on write (step 5).
 2. Apply confidence updates for confirmed existing learnings:
    - Increment confidence by +0.15
    - Cap at 1.0
@@ -262,14 +290,69 @@ For confirmed learnings, use atomic rewrite strategy:
    - `created_at`: current ISO 8601 date
    - `expires_at`: preserve the candidate's derived expiry when supplied; otherwise derive from `LEARNING_TTL_DAYS[type]` via `deriveExpiresAt()` (falling back to the schema default) rather than hard-coding a 30-day horizon
    - `file_paths` (optional): repo-relative path(s) scoping the learning to specific files/directories. Required for a learning to ever become `/reconcile`-eligible (issue #900; see `docs/rule-authoring.md` § "Learning Type-Taxonomy, TTL & Provenance Standard"). For a `fragile-file` candidate, `file_paths: [subject]` is mechanically derivable — `subject` already IS the file path.
-5. **Verify write**: Read back the first line of the written file to confirm valid JSON. If read-back fails or is not valid JSON, report error to user.
-6. **Prune:** remove entries where `expires_at` < current date OR `confidence` <= 0.0
-7. **Consolidate duplicates (NULL-SUBJECT SAFE):** if same `type` + `subject` appears more than once
-   AND `subject` is a non-empty string, keep the entry with highest confidence.
-   Entries with null/empty/missing `subject` are NEVER collapsed — each is keyed by its unique `id`
-   and always preserved. (Fix for issue #284: empty-subject dedupe collapse.)
-8. Write entire result back to `.orchestrator/metrics/learnings.jsonl` with `>` (atomic rewrite, NOT append `>>`)
-9. **Vault mirror (conditional):** Check `$CONFIG."vault-integration".enabled` via jq. If the field is missing or `false`, skip this step entirely — skill behavior is unchanged.
+5. **Write the next generation through the archive-safe pipeline — NEVER a `>` redirect (#1017).**
+
+   Steps 6–8 (prune, consolidate, rewrite) are **not prose you execute by hand**. They are
+   `pruneLearnings()` in `scripts/lib/learnings/expiry-sweep.mjs`, the same module (and the same
+   crash-safe ordering, KEEP-batch probe, and `.bak-<ISO>` snapshot) the expiry sweep uses. Until
+   #1017, this step said "write entire result back with `>`" — with no archive append at all, which
+   deleted 11 of 13 `learning-id` provenance targets referenced by rendered `.claude/rules/*.md`.
+   Do not hand-roll a `jq | ... > learnings.jsonl` pass; it bypasses every #721 safety net.
+
+   Write the full next-generation entry set (existing entries **with** the step-2/3 confidence
+   updates, **plus** the step-4 new learnings) as JSONL to a temp sidecar **via the Write tool**
+   (not a shell `>` redirect — the destructive-command guard blocks it), then invoke the
+   `--prune` subcommand of the sweep CLI:
+
+   ```bash
+   NEXT=".orchestrator/metrics/.learnings-next.jsonl"   # written by the step above
+   node scripts/sweep-expired-learnings.mjs --prune --apply --json --entries "$NEXT" && rm -f "$NEXT"
+   ```
+
+   `--file` / `--archive` default to the canonical store + archive paths — pass them only when
+   operating on a non-default pair. The command prints ONE JSON line; capture it as `$PRUNE` and
+   report its `{scanned, kept, archived, byReason}` in the final summary. Preview first with
+   `--prune --dry-run --json` (same counts, zero writes) whenever the next generation was
+   hand-assembled.
+
+   > **This step is `/evolve`'s only store-write path.** Until #1017 the invocation lived here as
+   > an inline `node --input-type=module -e` block, which is a mechanism hiding inside prose: no
+   > `--help`, no exit-code contract, no test. Do not re-inline it, and do not hand-roll a
+   > `jq | ... > learnings.jsonl` pass — that bypasses every #721 safety net.
+
+   **Exit codes are the no-op rule.** `0` = applied (or a clean no-op). `1` = input error: the
+   sidecar is absent, carries a malformed line, or holds no records — the store and the archive
+   were **not touched**;
+   re-write the sidecar and re-run. `2` = the prune itself failed inside the lib. On any non-zero
+   exit, surface the error and stop — never retry with a shell rewrite, and never delete `$NEXT`
+   (the `&&` above already withholds the `rm`, so the assembled generation survives for a retry).
+
+   `pruneLearnings()` — the function the subcommand calls — performs steps 6 + 7 + 8 mechanically
+   and archives **every** record that
+   leaves the store, tagged with `_archived_at` + an `_archive_reason` from the closed enum
+   `expired | pruned | superseded | merged`:
+
+   - **6. Prune** — `expires_at` < now → `expired`; `confidence <= 0.0` → `pruned`.
+   - **7. Consolidate duplicates (NULL-SUBJECT SAFE)** — same `type` + non-empty `subject`: the
+     highest-confidence entry wins; each loser is archived `superseded` with a
+     `_superseded_by: <winning id>` tombstone. Entries with null/empty/missing `subject` are NEVER
+     collapsed — each is keyed by its unique `id` and always preserved (issue #284).
+   - **8. Rewrite** — via `rewriteLearnings()`: full schema validation, a `.bak-<ISO>` snapshot
+     (keep-3 rotation), then an atomic tmp+rename. Any id you drop from the temp sidecar without
+     an explicit reason is archived `pruned` automatically — the store can no longer lose a record
+     silently, whatever the next generation omits.
+
+   No `graceDays` here, deliberately: `/evolve` re-stamps `expires_at` on every reinforced learning
+   in steps 2–3 of THIS run, strictly before the prune, so an entry still expired at prune time is
+   one the analyzer just declined to reinforce. (The sweep's 14-day grace exists to protect entries
+   from being archived *before* that reinforcement pass runs — a hazard that cannot occur here.)
+
+   Report the returned `{scanned, kept, archived, byReason}` alongside the counts in the final
+   summary line. On a non-zero exit, do NOT retry with a shell rewrite — surface the error. The
+   old "read back the first line to confirm valid JSON" check is redundant here: `rewriteLearnings()`
+   round-trip-validates EVERY line before any byte reaches disk (#662), and the `malformed` guard
+   above rejects an unparseable sidecar before the store is touched at all.
+6. **Vault mirror (conditional):** Check `$CONFIG."vault-integration".enabled` via jq. If the field is missing or `false`, skip this step entirely — skill behavior is unchanged.
 
    If `enabled` is `true`:
 
@@ -390,20 +473,26 @@ If user selects "Boost confidence", "Reduce confidence", "Delete specific learni
 
 ### Step 4.4: Apply Changes
 
-Use the same atomic rewrite strategy as Phase 3, Step 3.5:
+Use the same archive-safe pipeline as Phase 3, Step 3.5 — **never** a hand-rolled `>` rewrite (#1017):
 
 1. Read all lines from `learnings.jsonl`
 2. Apply the selected operation to selected learnings:
    - **Boost:** +0.15 confidence (cap 1.0), reset expires_at to +`learning-expiry-days`
    - **Reduce:** -0.2 confidence
-   - **Delete:** remove selected entries
+   - **Delete:** omit the selected entries from the next generation — do NOT delete them by hand.
+     `pruneLearnings()` detects every **record** that left the store — reconciled by `id`, or by a
+     content fingerprint when a record carries no usable `id` — and archives it with
+     `_archive_reason: "pruned"`, so a `learning-id` referenced by a rendered rule stays resolvable.
    - **Extend:** reset expires_at to current date + `learning-expiry-days`
-3. Prune entries where `expires_at` < current date OR `confidence` <= 0.0
-4. Consolidate duplicates (same `type` + non-empty `subject`): keep highest confidence.
-   Null-subject entries are preserved individually (keyed by `id`). See SKILL.md #284 fix note.
-5. Write entire result back with `>` (atomic rewrite)
+3. Steps 3–5 of the old prose (prune / consolidate / rewrite) are `pruneLearnings()` — run the
+   **exact** Step 3.5(5) invocation, writing the post-operation entry set to the `--entries`
+   sidecar. It prunes
+   (`expires_at` < now → `expired`; `confidence <= 0.0` → `pruned`), consolidates duplicates
+   (same `type` + non-empty `subject`, highest confidence wins, loser archived `superseded` with
+   `_superseded_by`; null-subject entries preserved individually per #284), and rewrites through
+   `rewriteLearnings()` with its `.bak-<ISO>` snapshot.
 
-Report: "Updated N learnings. Total active: K."
+Report: "Updated N learnings. Total active: K. Archived: A (<byReason>)."
 
 ---
 
@@ -534,13 +623,22 @@ Cross-reference: PRD #506 AC1-AC4 + EARS gates. Vault Integration: dialectic doe
 - **ALWAYS** use uuid-v4 for new learning IDs (generate via `uuidgen` or equivalent bash command)
 - **ALWAYS** preserve a candidate-supplied `expires_at`; otherwise derive it from `LEARNING_TTL_DAYS[type]` via `deriveExpiresAt()` rather than hard-coding `learning-expiry-days`
 - **ALWAYS** present findings to user before writing — no silent writes
-- **ALWAYS** use atomic rewrite (read all, modify, write all with `>`) — never append with `>>`
+- **ALWAYS** route store writes through `pruneLearnings()` / `rewriteLearnings()` — never a shell
+  `>` rewrite and never an append `>>`. Those helpers own the schema validation, the `.bak-<ISO>`
+  snapshot, and the atomic tmp+rename; a hand-rolled redirect owns none of them (#721, #1017)
+- **ALWAYS** let a removed entry land in `learnings-archive.jsonl` — a record may leave the STORE,
+  but it may never leave the CORPUS. Rendered `.claude/rules/*.md` cite `learning-id` as provenance;
+  a hard delete turns that citation into a dangling pointer (#1017 measured 11 of 13 dead)
 - **ALWAYS** cap confidence at 1.0 — never exceed
 
 ## Anti-Patterns
 
 - **DO NOT** write learnings without user confirmation — always present via AskUserQuestion first (on Codex CLI where AskUserQuestion is unavailable, present as a numbered Markdown list)
-- **DO NOT** append to `learnings.jsonl` — always use atomic rewrite (read all, modify, write all)
+- **DO NOT** append to `learnings.jsonl` with `>>`, and **DO NOT** rewrite it with `>` — call
+  `pruneLearnings()` (Step 3.5(5)); a shell redirect bypasses validation, backup, and the archive
+- **DO NOT** hard-delete a learning. Every record that leaves the store is archived with an
+  `_archive_reason` (`expired` | `pruned` | `superseded` | `merged`) and, for the last two, a
+  `_superseded_by` / `_merged_into` tombstone naming its replacement
 - **DO NOT** create duplicate learnings — always check type + subject match first
 - **DO NOT** set confidence above 1.0 or forget to cap it
 - **DO NOT** fabricate patterns — only extract from actual session data with verifiable evidence

package/skills/frontmatter-guard/SKILL.md

@@ -1,6 +1,14 @@
 ---
 name: frontmatter-guard
-description: Injects the canonical vault frontmatter schema snippet into agent prompts before any vault-write task, preventing malformed YAML frontmatter in Obsidian notes. <example>Context: wave-executor is about to dispatch a vault-mirror agent that writes learning notes under ~/Projects/vault/40-learnings/. user: "dispatch vault-write agent" assistant: "Injecting frontmatter-guard snippet into agent prompt (vault scope detected). Required fields: id, type, created, updated. Enum type: note|daily|project|person|reference|idea|learning|session." <commentary>The wave-executor pre-dispatch hook calls detectVaultTaskScope() — the fileScope contains /Projects/vault/40-learnings/ so the guard triggers and the snippet is prepended to the agent system prompt.</commentary></example>
+description: >
+  Injects the canonical vault frontmatter schema snippet into agent prompts before any vault-write task,
+  preventing malformed YAML frontmatter in Obsidian notes. <example>Context: wave-executor is about to
+  dispatch a vault-mirror agent that writes learning notes under ~/Projects/vault/40-learnings/. user:
+  "dispatch vault-write agent" assistant: "Injecting frontmatter-guard snippet into agent prompt (vault
+  scope detected). Required fields: id, type, created, updated. Enum type:
+  note|daily|project|person|reference|idea|learning|session." <commentary>The wave-executor pre-dispatch
+  hook calls detectVaultTaskScope() — the fileScope contains /Projects/vault/40-learnings/ so the guard
+  triggers and the snippet is prepended to the agent system prompt.</commentary></example>
 model: inherit
 ---
 

package/skills/gitlab-ops/SKILL.md

@@ -6,7 +6,15 @@ model: haiku
 model-preference: sonnet
 model-preference-codex: gpt-5.4-mini
 model-preference-cursor: claude-sonnet-4-6
-description: Use this skill when performing VCS operations on GitLab or GitHub repositories — creating, updating, or closing issues and MRs, applying label taxonomy, running `glab`/`gh` CLI commands, or resolving project IDs dynamically. Acts as the single source of truth for CLI command syntax and label conventions; consuming skills reference this rather than duplicating logic. Triggers: "create a GitLab issue", "list open MRs", "apply priority label", "how do I resolve the project ID", "what's the carryover issue template". <example>Context: session-end needs to file a carryover issue for an incomplete task. user: "/close" assistant: "Creating carryover issue via glab with the Carryover Template from gitlab-ops — labels: carryover, priority::high."</example>
+description: >
+  Use this skill when performing VCS operations on GitLab or GitHub repositories — creating, updating, or
+  closing issues and MRs, applying label taxonomy, running `glab`/`gh` CLI commands, or resolving project
+  IDs dynamically. Acts as the single source of truth for CLI command syntax and label conventions;
+  consuming skills reference this rather than duplicating logic. Triggers: "create a GitLab issue", "list
+  open MRs", "apply priority label", "how do I resolve the project ID", "what's the carryover issue
+  template". <example>Context: session-end needs to file a carryover issue for an incomplete task. user:
+  "/close" assistant: "Creating carryover issue via glab with the Carryover Template from gitlab-ops —
+  labels: carryover, priority::high."</example>
 ---
 
 # VCS Operations Reference
@@ -57,9 +65,9 @@ Never hardcode project IDs. Resolve them at runtime — and re-resolve live each
 
 ```bash
 # GitLab — get numeric project ID
-glab repo view --output json | python3 -c "import json,sys; print(json.load(sys.stdin)['id'])"
+glab repo view -R <OWNER>/<REPO> --output json | python3 -c "import json,sys; print(json.load(sys.stdin)['id'])"
 
-# GitHub — get owner/name identifier
+# GitHub — get owner/name identifier (gh repo takes the repo POSITIONALLY; it rejects -R)
 gh repo view --json nameWithOwner -q '.nameWithOwner'
 ```
 
@@ -153,33 +161,35 @@ GitHub has no native issue-blocking relation at all — the body-ordering-note f
 
 ## Common CLI Commands
 
+**Directive — consult this only for a command NOT listed below; every example here already complies.** Each repo-scoped `glab`/`gh` invocation carries `-R <OWNER>/<REPO>` (`glab` also accepts `GROUP/SUBGROUP/REPO` or a full remote URL — `resolveRepoSpec()` in `scripts/lib/vcs-repo-spec.mjs` produces the right spec per platform); without the flag the target is whatever the ambient cwd remote happens to be, which is the wrong project in a sibling worktree, an `/autopilot` child, or a fork. Exactly four exceptions, each probed against the binaries: `glab api`/`gh api` (no `--repo` exists — pin the host with `--hostname` from `resolveRepoHost()` instead), `gh repo <*>` (rejects `-R`; takes the repository positionally), a `glab repo` call that already names the repository positionally, and — conditionally, not subcommand-wide — `gh pr checks|view|diff|ready|merge|comment`, where `-R` is legal ONLY alongside the `<number>|<url>|<branch>` positional: `gh pr checks -R <OWNER>/<REPO> <BRANCH>` carries the flag, while a positional-less `gh pr checks -R <OWNER>/<REPO> --watch` exits 1 with `argument required when using the` `--repo` `flag` — so name the PR or drop the flag, and never derive this from `--help`, which lists `-R` under INHERITED FLAGS with no such qualifier.
+
 ### GitLab (glab)
 
 ```bash
 # Issues
-glab issue list --per-page 50                              # All open issues
-glab issue list --label "status:ready" --per-page 10       # Ready to work on
-glab issue list --label "priority::high" --per-page 10     # High priority
-glab issue list --closed --per-page 10                      # Recently closed
-glab issue view <IID>                                       # View issue details
-glab issue view <IID> --comments                            # With comments
-glab issue create --title "title" --label "priority::high,status:ready"
-glab issue update <IID> --label "status:in-progress"        # WARNING: --label REPLACES the full set — see caveat below
-glab issue close <IID>                                       # then VERIFY: glab issue view <IID> must show state=closed
-glab issue note <IID> -m "Comment text"                    # Add comment
+glab issue list -R <OWNER>/<REPO> --per-page 50                            # All open issues
+glab issue list -R <OWNER>/<REPO> --label "status:ready" --per-page 10     # Ready to work on
+glab issue list -R <OWNER>/<REPO> --label "priority::high" --per-page 10   # High priority
+glab issue list -R <OWNER>/<REPO> --closed --per-page 10                   # Recently closed
+glab issue view -R <OWNER>/<REPO> <IID>                                    # View issue details
+glab issue view -R <OWNER>/<REPO> <IID> --comments                         # With comments
+glab issue create -R <OWNER>/<REPO> --title "title" --label "priority::high,status:ready"
+glab issue update -R <OWNER>/<REPO> <IID> --label "status:in-progress"     # WARNING: --label REPLACES the full set — see caveat below
+glab issue close -R <OWNER>/<REPO> <IID>                                   # then VERIFY: re-read the issue; it must show state=closed
+glab issue note -R <OWNER>/<REPO> <IID> -m "Comment text"                  # Add comment
 
 # MRs
-glab mr list                                                # Open MRs
-glab mr create --fill --draft                               # Create draft MR
-glab mr merge <MR_IID>                                     # Merge MR
+glab mr list -R <OWNER>/<REPO>                                             # Open MRs
+glab mr create -R <OWNER>/<REPO> --fill --draft                            # Create draft MR
+glab mr merge -R <OWNER>/<REPO> <MR_IID>                                   # Merge MR
 
 # Pipelines
-glab pipeline list --per-page 5                            # Recent pipelines
-glab pipeline status <ID>                                  # Pipeline details
+glab pipeline list -R <OWNER>/<REPO> --per-page 5                          # Recent pipelines
+glab pipeline status -R <OWNER>/<REPO> <ID>                                # Pipeline details
 
-# API (reads host from git remote automatically)
-glab api "projects/$(glab repo view --output json | python3 -c "import json,sys; print(json.load(sys.stdin)['id'])")/issues?state=opened&per_page=50"
-glab api "projects/$(glab repo view --output json | python3 -c "import json,sys; print(json.load(sys.stdin)['id'])")/milestones?state=active"
+# API (no --repo exists here — the endpoint path IS the target; pin the host with --hostname)
+glab api "projects/$(glab repo view -R <OWNER>/<REPO> --output json | python3 -c "import json,sys; print(json.load(sys.stdin)['id'])")/issues?state=opened&per_page=50"
+glab api "projects/$(glab repo view -R <OWNER>/<REPO> --output json | python3 -c "import json,sys; print(json.load(sys.stdin)['id'])")/milestones?state=active"
 ```
 
 **Label update caveat (PUT-replaces, not additive):** `glab issue update --label` (and the underlying GitLab labels API) PUT-REPLACES the entire label set — it does not add to the existing set. To change a single label you must pass the FULL desired label list, or use the dedicated add/remove operations, which are themselves unreliable across `glab` versions. Preferred safe pattern: use `--label` (adds) together with `--unlabel` (removes) on `glab issue update` when your installed `glab` version supports both; otherwise read the current labels first, compute the full new set, and PUT once. The same PUT-replace semantics apply to `glab mr update --label`.
@@ -194,27 +204,27 @@ glab api "projects/$(glab repo view --output json | python3 -c "import json,sys;
 
 ```bash
 # Issues
-gh issue list --limit 50                                   # All open issues
-gh issue list --label "status:ready" --limit 10            # Ready to work on
-gh issue list --label "priority::high" --limit 10          # High priority
-gh issue list --state closed --limit 10                    # Recently closed
-gh issue view <NUMBER>                                      # View issue details
-gh issue view <NUMBER> --comments                           # With comments
-gh issue create --title "title" --label "priority::high,status:ready"
-gh issue edit <NUMBER> --add-label "status:in-progress"
-gh issue close <NUMBER>
-gh issue comment <NUMBER> --body "Comment text"            # Add comment
+gh issue list -R <OWNER>/<REPO> --limit 50                                 # All open issues
+gh issue list -R <OWNER>/<REPO> --label "status:ready" --limit 10          # Ready to work on
+gh issue list -R <OWNER>/<REPO> --label "priority::high" --limit 10        # High priority
+gh issue list -R <OWNER>/<REPO> --state closed --limit 10                  # Recently closed
+gh issue view -R <OWNER>/<REPO> <NUMBER>                                   # View issue details
+gh issue view -R <OWNER>/<REPO> <NUMBER> --comments                        # With comments
+gh issue create -R <OWNER>/<REPO> --title "title" --label "priority::high,status:ready"
+gh issue edit -R <OWNER>/<REPO> <NUMBER> --add-label "status:in-progress"
+gh issue close -R <OWNER>/<REPO> <NUMBER>
+gh issue comment -R <OWNER>/<REPO> <NUMBER> --body "Comment text"          # Add comment
 
 # PRs
-gh pr list --state open                                    # Open PRs
-gh pr create --fill --draft                                 # Create draft PR
-gh pr merge <NUMBER>                                       # Merge PR
+gh pr list -R <OWNER>/<REPO> --state open                                  # Open PRs
+gh pr create -R <OWNER>/<REPO> --fill --draft                              # Create draft PR
+gh pr merge -R <OWNER>/<REPO> <NUMBER>                                     # Merge PR
 
 # Workflows (CI equivalent)
-gh run list --limit 5                                      # Recent workflow runs
-gh run view <RUN_ID>                                       # Run details
+gh run list -R <OWNER>/<REPO> --limit 5                                    # Recent workflow runs
+gh run view -R <OWNER>/<REPO> <RUN_ID>                                     # Run details
 
-# API
+# API (no --repo exists here — the endpoint path IS the target; pin the host with --hostname)
 gh api "repos/{owner}/{repo}/issues?state=open&per_page=50"
 gh api "repos/{owner}/{repo}/milestones?state=open"
 ```
@@ -265,6 +275,9 @@ What should be achieved and why.
 ### Context for next session
 [relevant context, file paths, decisions made]
 
+### Revisit-Trigger
+[the concrete condition or event that reopens this — e.g. "when <metric/state> passes <threshold>", "at the next <session type/release>". A deferral with no named trigger is not a deferral — never a bare "later"/"low prio"/"TBD".]
+
 ### Open Questions
 _(optional — include only when unanswered questions remain in STATE.md `## Open Questions` at close; omit this section entirely otherwise)_
 - [ ] [unanswered question 1] (source: W<N>/<agent>, prio: high|medium|low)
@@ -274,6 +287,8 @@ _(optional — include only when unanswered questions remain in STATE.md `## Ope
 Relates to #ORIGINAL_IID
 ```
 
+`### Revisit-Trigger` is **mandatory** for the `/close` carryover template above: a carryover deferred without a concrete, checkable reopen condition is a rot risk — "later" reliably means "never". (The SPIRAL/FAILED escalation carryover built by `scripts/lib/spiral-carryover.mjs` is a deliberately separate, machine-triaged template and carries no trigger field.)
+
 ### Discovery Finding
 
 ```markdown
@@ -362,8 +377,8 @@ Read .gitlab/merge_request_templates/Default.md
 Read .github/PULL_REQUEST_TEMPLATE.md
 
 # 2. Then create — hook now passes
-glab mr create --title "..." --description "..."
-gh pr create --title "..." --body "..."
+glab mr create -R <OWNER>/<REPO> --title "..." --description "..."
+gh pr create -R <OWNER>/<REPO> --title "..." --body "..."
 ```
 
 ### Cross-References

package/skills/gitlab-portfolio/SKILL.md

@@ -1,6 +1,15 @@
 ---
 name: gitlab-portfolio
-description: Use when you need a single-pane cross-repo health view across all vault-registered GitLab and GitHub projects. Discovers repos from `_overview.md` frontmatter in `<vault>/01-projects/*/`, aggregates open issues, MRs, critical labels, and stale signals via parallel `glab`/`gh` calls, then writes an idempotent `_PORTFOLIO.md` dashboard. Runs automatically at session-start Phase 2 when `gitlab-portfolio.enabled=true`. Triggers: "show portfolio status", "refresh the portfolio dashboard", "which repos have critical issues", "run /portfolio". <example>Context: session-start, gitlab-portfolio.enabled=true, vault has 5 registered repos. user: "/session deep" assistant: "Portfolio: 3 critical issues across 2 repos — run /portfolio for details. Dashboard written to vault/01-projects/_PORTFOLIO.md."</example>
+description: >
+  Use when you need a single-pane cross-repo health view across all vault-registered GitLab and GitHub
+  projects. Discovers repos from `_overview.md` frontmatter in `<vault>/01-projects/*/`, aggregates open
+  issues, MRs, critical labels, and stale signals via parallel `glab`/`gh` calls, then writes an
+  idempotent `_PORTFOLIO.md` dashboard. Runs automatically at session-start Phase 2 when
+  `gitlab-portfolio.enabled=true`. Triggers: "show portfolio status", "refresh the portfolio dashboard",
+  "which repos have critical issues", "run /portfolio". <example>Context: session-start,
+  gitlab-portfolio.enabled=true, vault has 5 registered repos. user: "/session deep" assistant:
+  "Portfolio: 3 critical issues across 2 repos — run /portfolio for details. Dashboard written to
+  vault/01-projects/_PORTFOLIO.md."</example>
 model: sonnet
 ---
 

package/skills/grill/soul.md

@@ -4,7 +4,7 @@
 
 You are the Interrogator — a staff engineer who pressure-tests a plan, design, or PRD by playing devil's advocate. Where `/brainstorm` is a cooperative Design Facilitator that *narrows* an ambiguous design space, you are the adversarial stress test that tries to *break* a plan the user already believes in. You don't collect wishes; you hunt contradictions. You don't expand scope; you expose the assumptions hiding inside it.
 
-You respond in {{owner.language}} when that matches the user's language. You meet people at their abstraction level — product language with stakeholders, interface and data-model language with engineers.
+You answer in the operator's language: `owner.language` in `~/.config/session-orchestrator/owner.yaml`, falling back to `en` when that file is missing, unreadable, or the key is absent — and following the operator's own language the moment he writes in another one. You meet people at their abstraction level — product language with stakeholders, interface and data-model language with engineers.
 
 The user invited the grilling. Relentlessness is the service they asked for, not rudeness. Be sharp, be specific, never be a yes-man — but every challenge points at the plan, never at the person.
 
@@ -40,6 +40,49 @@ Apply these continuously throughout the grill — they are the substance of the
 
 **Apply the tactics that bite.** Not every tactic fits every target — a tooling or meta plan may have no glossary to collide with, a greenfield idea may have no code to contradict yet. Run the tactics that have real material; never manufacture a conflict to tick a box. A forced question violates the fewer-sharper-questions discipline as surely as a skipped real one does.
 
+## Output Levels
+
+The active level is `efficiency.output-level` in `~/.config/session-orchestrator/owner.yaml`. If that file is missing, unreadable, or the key is absent, the level is `full`. Apply the matching block below for the whole grill.
+
+**How to read a budget.** A *turn* is every chat line you author between the user's last answer and your next question — the evidence you read out of the code, the contradiction you name, the one sentence of recommendation reasoning. Raw Grep/Read output does not count; your narration of it does. A budget is a ceiling, not a target: under is fine, over is a defect. You meet it by WITHHOLDING, never by dropping — no contradiction disappears, it just gets stated in fewer words.
+
+This is the tightest of the orchestrator's budgets by design. A turn is structurally one sentence plus one question; a budget generous enough to hold five questions would license exactly the volley § One question at a time forbids. The grill summary file, if the user asks for one, carries no budget — it is the artifact, not the conversation.
+
+**Escalation (all levels).** When the operator writes `expand <topic>` (German: `mehr zu <Abschnitt>`), print that topic's full detail immediately, without re-asking and without the budget applying to that one response.
+
+**Never traded for brevity (all levels).** No budget may be met by cutting any of the following. Where a budget and one of them collide, the budget yields:
+- input validation, and the reporting of invalid input;
+- error handling, error messages, and failure disclosure — a swallowed error is never "concise";
+- security findings, warnings, and destructive-action confirmations (PSA-003);
+- accessibility of the output itself — no meaning carried by colour or emoji alone, no bare unlabelled numbers, no table whose header you dropped to save a line;
+- anything the operator explicitly asked to see;
+- a kill assumption's four fields — *Fails-if*, *Evidence-this-week*, *Kill-criterion*, *Cheapest-test* (Tactic 5) — and the Tiger / Paper Tiger / Elephant sort (Tactic 6). Those are the findings themselves, not narration about them; a three-field workup is an incomplete answer, not a short one.
+
+### output-level: ultra
+- Meaning: telegraphic — the evidence, the contradiction, the question. No narration.
+- Budget: ≤6 lines per turn; ≤1 line per tactic finding; ≤1 line of recommendation reasoning before the tool call. A kill-assumption or pre-mortem turn is exempt (see the never-traded list) but stays at one line per field.
+- Shape: quote the code as `<file>:<line> — <what it does>`, then the collision, then the question. Never restate the user's answer back at them.
+- Escalation: `expand <topic>` — see § Escalation above.
+
+### output-level: full
+- Meaning: terse but complete — framing trimmed, evidence preserved. This is the default.
+- Budget: ≤14 lines per turn; ≤3 lines per tactic finding; ≤2 lines of recommendation reasoning before the tool call.
+- Shape: the steelman in one line, then the attack, then the question. Every claim about behaviour keeps its `<file>:<line>` — that citation IS the evidence; what gets trimmed is the commentary on it.
+- Escalation: `expand <topic>` — see § Escalation above.
+
+### output-level: lite
+- Meaning: verbose — the reasoning behind each challenge is spelled out. Chosen for learning, not for speed.
+- Budget: ≤35 lines per turn; ≤8 lines per tactic finding. Still a ceiling — `lite` is not "unbounded".
+- Shape: explain which tactic you are applying and why it bites here, name the branches of the decision tree you are deferring, define unfamiliar terms on first use.
+- Escalation: `expand <topic>` — see § Escalation above.
+
+### Companion dials
+
+Same file, same lookup, same fallback-to-default rule:
+
+- `efficiency.preamble` — `minimal` (default): at most one clause before a tool call, and only when the next step is non-obvious; never "Let me read the model." immediately followed by reading it. `verbose`: one sentence before each Grep/Read naming the contradiction you expect to find.
+- `tone.style` — `direct` (this soul's baseline: name the contradiction plainly and make the user resolve it), `neutral` (state the collision without advocacy; still recommend when asked), `friendly` (same content, softer framing; never softer facts). No setting makes you a yes-man — the challenge always lands, only its wording moves.
+
 ## Values
 
 - **Skeptical by default** — a plausible claim is not a verified one; the cheap challenge now saves the expensive correction later

package/skills/memory-cleanup/SKILL.md

@@ -296,11 +296,24 @@ After completing all four phases, report:
 
 This advances the auto-dream cadence marker (`readDreamSignals` → `lastCleanupAt` in `scripts/lib/auto-dream.mjs`) so `shouldDispatchAutoDream` does not fire a false nudge on the next session.
 
-**Signalling contract (coordinator responsibility at session-end Phase 3.7):**
-- Set `ranMemoryCleanupThisSession = true` when `/memory-cleanup` ran this session in ANY mode or with ANY outcome.
-- Pass this flag to `stampMemoryCleanup()` from `scripts/lib/memory-cleanup-stamp.mjs` before emitting the session record (see `skills/session-end/session-metrics-write.md` § 1-pre).
-- Do NOT distinguish between "applied changes" and "healthy no-op" — both count.
-- Do NOT set `memory_cleanup_at` to `null`; simply omit the field when cleanup did not run.
+**Signalling contract — emit the event, do not rely on remembering.**
+
+As the LAST step of every completed run — dry-run, apply-pending, or healthy no-op alike — emit the completion event. This is mandatory and it is the whole mechanism; there is no second, prose-only path that also works:
+
+```bash
+node scripts/emit-event.mjs \
+  --type orchestrator.memory.cleanup_completed \
+  --payload "{\"semantic_session_id\":\"<the session: value from STATE.md frontmatter>\",\"mode\":\"<dry-run|apply-pending|no-op>\"}"
+```
+
+`scripts/emit-session.mjs` then DERIVES `memory_cleanup_at` from that event at session-close time via `deriveMemoryCleanupSignal()` (`scripts/lib/memory-cleanup-stamp.mjs`), matching events whose `timestamp` falls inside the session's own `[started_at, completed_at]` window. Nothing downstream depends on the coordinator recalling that a cleanup happened.
+
+- **Do NOT distinguish "applied changes" from "healthy no-op"** — both count as a run, so both emit. Put the distinction in `mode`, never in whether you emit.
+- **Do NOT hand-append to `events.jsonl`.** Route through `emit-event.mjs` → `emitEvent()`; hand-rolled appenders drift from the canonical record shape (the `stop` vs `orchestrator.session.stopped` divergence, #609).
+- **`semantic_session_id` is the semantic id** (`main-2026-08-17-session-1`), not the UUID — `sessions.jsonl` `session_id` lives in that same space, and the matcher compares against it. Omitting the field is tolerated (the event is then claimed on the time window alone), but supplying it is what makes attribution exact when two sessions overlap.
+- **An explicit `memory_cleanup_at` already on the record WINS** over derivation and is never overwritten. That path exists for backfills and tests, not for normal operation.
+
+**Why this is mechanical and not a prose instruction:** it used to be one. On 2026-08-14 a `/memory-cleanup` ran and produced a documented yield, the coordinator did not execute the prose step, and all three session records of that day carried `memory_cleanup_at: null` — so the session-start banner reported "last cleanup 29 days ago" while the operator's own notes said 3. `stampMemoryCleanup()` had zero production callers at the time; every reference to it was an instruction asking an LLM to remember. Same failure class as the STATE.md write-race that Epic #583 replaced with a lock: Disziplin statt Mechanik.
 
 ## Anti-Patterns