session-orchestrator 3.17.0 → 3.20.0

package/skills/discovery/probes-session.md

@@ -91,7 +91,7 @@ gh issue list --limit 100 --json number,title,labels,updatedAt,assignees --jq '.
 # Flag:
 # - Issues with no activity in stale-issue-days (default: 30 days)
 # - Issues assigned but with no associated branch
-# - Issues labeled priority:high or priority:critical that are stale
+# - Issues labeled priority::high or priority::critical that are stale
 
 # Check for associated branches:
 git branch -r | grep -i "<issue_number>"
@@ -109,7 +109,7 @@ Has Branch: true | false
 Priority: <priority label or NONE>
 ```
 
-**Default Severity:** Low. Medium if `priority:high` or `priority:critical` is stale.
+**Default Severity:** Low. Medium if `priority::high` or `priority::critical` is stale.
 
 ---
 
@@ -231,14 +231,35 @@ Actual: <what was found or NOT found>
 
 5. Token efficiency — CLAUDE.md size:
 ```bash
-# Count lines in CLAUDE.md
-wc -l CLAUDE.md
+# Delegate the threshold — do NOT re-implement it here. This probe used to
+# carry its own numbers (`wc -l` > 150 warn / > 250 high); both the unit and
+# the value were wrong. The ceiling is `DEFAULT_MAX_LINES = 80` and it applies
+# to NON-EXEMPT effective lines: the runtime-critical `## Session Config` block
+# is machine-parsed configuration, not trimmable prose, so a raw `wc -l` gate
+# flags a compliant lean-root file (this plugin's own CLAUDE.md: 209 raw lines,
+# 61 non-exempt — a `wc -l` rule fires, the lint passes).
+REPO_ROOT="$(git rev-parse --show-toplevel)"
+node "${PLUGIN_ROOT}/scripts/lib/claude-md-budget-lint.mjs" \
+  --repo-root "$REPO_ROOT" --mode warn --json
+# → {"status":"ok"|"invalid","file":…,"lineCount":…,"exemptLines":…,
+#    "effectiveLineCount":…,"maxLineCharsSeen":…,"hasProvenance":…,
+#    "violations":[{"rule":"max-lines"|"max-line-chars"|…,"message":…}]}
+# Flag ONLY on a violations[] entry — never on lineCount vs a local number.
+# `--mode warn` keeps the exit code 0, so read the JSON, not `$?`.
+
+# Ceiling value, when a finding needs to quote it (e.g. a 2x high tier):
+node --input-type=module -e "
+import { DEFAULT_MAX_LINES } from '${PLUGIN_ROOT}/scripts/lib/claude-md-budget-lint.mjs';
+process.stdout.write(String(DEFAULT_MAX_LINES));
+"
 
-# Flag if > 150 lines (warning) or > 250 lines (high)
+# Heuristics the lint does NOT measure — still eyeball these:
 # Identify sections > 30 lines that could move to <state-dir>/rules/ or <state-dir>/docs/
 # Check for inline code blocks > 10 lines (should be in separate files)
 ```
 
+**Dependencies (probe 5):** requires `${PLUGIN_ROOT}/scripts/lib/claude-md-budget-lint.mjs` (#722 Epic A). Degrades gracefully when the helper is absent (pre-#722 plugin install) — skip the size finding with a note, do not fall back to a hand-rolled `wc -l` threshold, which is the drift this delegation removes.
+
 6. Token efficiency — .claudeignore coverage:
 ```bash
 # Check if .claudeignore exists

package/skills/ecosystem-health/SKILL.md

@@ -91,7 +91,7 @@ and skip this section.
 Using the detected VCS CLI (per gitlab-ops "Common CLI Commands" and "Dynamic Project Resolution" sections):
 
 1. Resolve the project ID or owner/repo slug for each cross-repo
-2. Query open issues with `priority:critical` or `priority:high` labels (limit 5 per repo)
+2. Query open issues with `priority::critical` or `priority::high` labels (limit 5 per repo)
 3. Collect results across all configured repos
 
 ## CI Pipeline Status

package/skills/ecosystem-health/wizard.md

@@ -78,8 +78,8 @@ CI pipeline identifiers (format "id" or "id:label", comma-separated, blank to sk
 ### Prompt 2c — Critical Issue Labels
 
 ```
-Critical issue labels (comma-separated, e.g. "priority:critical,severity:blocker", blank to skip):
-> priority:critical, severity:blocker
+Critical issue labels (comma-separated, e.g. "priority::critical,severity:blocker", blank to skip):
+> priority::critical, severity:blocker
 ```
 
 - Raw label strings as they appear in the VCS issue tracker.
@@ -121,7 +121,7 @@ ecosystem-health:
   pipelines:
     - id: main
     - id: deploy-production # Deploy
-  critical-issue-labels: ["priority:critical", "severity:blocker"]
+  critical-issue-labels: ["priority::critical", "severity:blocker"]
 ```
 
 **Idempotency:** If an `ecosystem-health:` key already exists in Session Config,
@@ -141,7 +141,7 @@ exits 0. Re-run to edit: remove the existing block first, then re-run.
     { "id": "main" },
     { "id": "deploy-production", "label": "Deploy" }
   ],
-  "criticalIssueLabels": ["priority:critical", "severity:blocker"]
+  "criticalIssueLabels": ["priority::critical", "severity:blocker"]
 }
 ```
 

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
@@ -261,14 +289,70 @@ For confirmed learnings, use atomic rewrite strategy:
    - `source_session`: **non-empty kebab-slug string** identifying the session from which the pattern was extracted (e.g. `main-2026-04-27-1942`). MUST be a string — never an object, array, number, or null. If multiple sessions contributed, use the earliest. If unknown, use `"unknown"` (the string). **Never** pass `String(<object>)` — that yields `"[object Object]"` and breaks the YAML mirror downstream (#307). Optional pre-write validation: `jq -e 'select(.source_session | type == "string" and length > 2)'`.
    - `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
-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.
+   - `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. **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`:
 
@@ -389,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>)."
 
 ---
 
@@ -533,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/gitlab-ops/SKILL.md

@@ -6,7 +6,7 @@ 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
@@ -99,13 +99,21 @@ done
 
 ## Label Taxonomy
 
-**Taxonomy convention (decided 2026-07-05, #727):** labels use the SINGLE-COLON form exclusively (`priority:high`, `status:ready`, `area:vcs`, `type:chore`, `from:<agent>`). The `::`-scoped form (`priority::high`, GitLab scoped-labels) is DEPRECATED baseline-scaffold legacy and MUST NOT be introduced — this repo mirrors to GitHub, which has no scoped-label semantics (no mutual-exclusion enforcement), so `::` yields zero benefit on the mirror while a migration would break every existing label reference and issue.
+**Taxonomy convention — `priority` REVERSED to scoped `::` (supersedes #727 for this one axis).**
+
+- **`priority::<level>` is canonical.** #727's stated rationale was that "this repo mirrors to GitHub, which has no scoped-label semantics … while a migration would break every existing label reference and issue." Both halves were checked on 2026-07-25 and neither holds:
+  - **Issues are not mirrored at all.** `aiat-poc-infra/docs/github-mirror-runbook.md:1,5` describes a git **push-mirror** with GitHub as "read-only downstream"; `docs/gitlab-team-org-2026-06-21.md:45` confirms there is no two-way GitLab issue sync. Nothing crosses the boundary that a label rename could break.
+  - **GitHub already uses the scoped form.** `gh api "repos/AIAT-AIandBusinessgrowth/aiat-barrierefrei-engine/labels"` returns `priority::high`, `priority::low`, `priority::med`, `priority::medium` across 77 open issues, and **zero** `priority:high`. Same pattern on `aiat-doc-vlm`. GitHub treats `::` as an ordinary string; it merely does not enforce mutual exclusion.
+  - Volume agrees independently: **416 `priority::` against 249 `priority:` and 7 bare** at the time of the decision. Chasing the minority spelling would mean re-labelling the majority.
+  Producers were migrated FIRST (this change); the label-data migration follows separately, because migrating data before producers means the divergence returns within a day.
+- **`area:` / `type:` / `status:` / `from:` stay SINGLE-COLON** — but NOT on #727's rationale, which is disproven above. They stay because nothing measured argues for flipping them, and because each axis is its own migration cost. Flipping them is a separate decision and is explicitly NOT made here. Note that `status` in particular is the worst-disciplined axis on the instance (354 assignments, only 48 percent scoped, 5 genuine value conflicts), so any future flip there needs a conflict-resolution pass first.
+- **Readers accept both spellings.** Every consumer that MATCHES a label compares through `scripts/lib/label-scope.mjs` `normalizeLabel()`, which collapses `::` to `:` — so issues still carrying `priority:high` keep being counted until the data migration lands. Only WRITES are canonical.
 
 ### Priority Labels
-- `priority:critical` — blocking production or users
-- `priority:high` — important, schedule this sprint
-- `priority:medium` — plan for next sprint
-- `priority:low` — backlog, nice-to-have
+- `priority::critical` — blocking production or users
+- `priority::high` — important, schedule this sprint
+- `priority::medium` — plan for next sprint
+- `priority::low` — backlog, nice-to-have
 
 ### Status Labels
 - `status:ready` — defined, ready to pick up
@@ -151,11 +159,11 @@ GitHub has no native issue-blocking relation at all — the body-ordering-note f
 # 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 --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 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
@@ -188,11 +196,11 @@ glab api "projects/$(glab repo view --output json | python3 -c "import json,sys;
 # 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 --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 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
@@ -257,6 +265,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)
@@ -266,13 +277,15 @@ _(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
 ## [Discovery] <finding title>
 
 **Probe:** <probe_name>
-**Severity:** <priority:critical|high|medium|low>
+**Severity:** <priority::critical|high|medium|low>
 **Category:** <code|infra|ui|arch|session|audit|vault|feature>
 
 ### Finding
@@ -302,7 +315,7 @@ Relates to #ORIGINAL_IID
 - [ ] Quality gates pass after fix
 ```
 
-Labels: `type:discovery`, `priority:<level>`, `area:<inferred>`, `status:ready`
+Labels: `type:discovery`, `priority::<level>`, `area:<inferred>`, `status:ready`
 
 ## Template-First Enforcement (PSA-005 + #519)
 

package/skills/gitlab-portfolio/SKILL.md

@@ -93,7 +93,7 @@ gitlab-portfolio:
   enabled: true
   mode: warn          # warn | strict | off
   stale-days: 30
-  critical-labels: ["priority:critical", "priority:high"]
+  critical-labels: ["priority::critical", "priority::high"]
 ```
 
 | Field | Default | Meaning |
@@ -101,7 +101,7 @@ gitlab-portfolio:
 | `enabled` | `false` | Master switch. |
 | `mode` | `warn` | `warn` / `strict` / `off` — failure handling; `off` ≡ disabled. |
 | `stale-days` | `30` | Issues older than N days are flagged stale. |
-| `critical-labels` | `["priority:critical","priority:high"]` | Label substrings that classify an issue as critical (case-insensitive). |
+| `critical-labels` | `["priority::critical","priority::high"]` | Label substrings that classify an issue as critical (case-insensitive). |
 
 ### Security
 

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/hook-development/SKILL.md

@@ -292,7 +292,7 @@ enabled=$(jq -r '.strictMode // false' "$CONFIG_FILE" 2>/dev/null)
 
 ## Our in-house examples (read these, not the upstream `examples/`)
 
-- `hooks/pre-bash-destructive-guard.mjs` — policy-driven command blocker, 13 rules in `.orchestrator/policy/blocked-commands.json`
+- `hooks/pre-bash-destructive-guard.mjs` — policy-driven command blocker, 14 rules in `.orchestrator/policy/blocked-commands.json`
 - `hooks/enforce-scope.mjs` — wave-scope boundary enforcement using `.orchestrator/wave-scope.json`
 - `hooks/on-session-start.mjs` — banner + session init
 - `hooks/post-edit-validate.mjs` — validates edits after the fact

package/skills/mode-selector/SKILL.md

@@ -216,7 +216,7 @@ Missing signal fields contribute 0 to the score — no NaN propagation.
 ## Open Questions (for Phase B-1 follow-up)
 
 - Learnings freshness window — default 30d? Configurable per-type or a single global TTL?
-- Backlog priority weighting — rule-based (`priority:critical = +0.2` confidence bonus) vs.
+- Backlog priority weighting — rule-based (`priority::critical = +0.2` confidence bonus) vs.
   learned from historical completion rates?
 - Alternative-generation algorithm — top-N non-selected modes scored by partial signal match, or
   fixed set derived from v0 heuristic branches?

package/skills/npm-publish/SKILL.md

@@ -29,7 +29,23 @@ Create at https://www.npmjs.com/settings/<user>/tokens → Generate New Token
 
 **Never** put the token in the tracked `.npmrc` (it holds `ignore-scripts=true` per SEC-020 and is committed), never persist it into `~/.npmrc`, never echo it into logs.
 
-## Publish flow
+## Canonical path: `scripts/release.mjs` (Release als ein Dispatch, #978)
+
+Since v3.19.0 the release is ONE dispatch — the script mechanizes every step below plus the
+version-surface sync this skill previously left to operator memory (the gap that let v3.18.0
+ship tagged but unpublished):
+
+```bash
+node scripts/release.mjs --set-version X.Y.Z   # rewrite all 12 version literals (10 files) + codex cachebuster + lock sync
+# … author CHANGELOG entry + README highlights (enforced by --check) …
+node scripts/release.mjs --check               # preflight: surfaces, CHANGELOG, tag/registry collision, CI green, leakage gate
+node scripts/release.mjs --publish             # token publish → registry verify → tag AFTER publish → push origin+github
+```
+
+The tag is created only AFTER a registry-verified publish — never before. The manual flow
+below remains as the fallback and as documentation of what the script does.
+
+## Publish flow (manual fallback)
 
 ```bash
 # 1. Pre-flight (first publish: expect E404 = name free; upgrade: expect the previous version)

package/skills/plan/SKILL.md

@@ -376,9 +376,9 @@ The Epic issue's number is not known during § 5.5.1. Once Phase 6 creates it, s
 
 Score each issue using three factors:
 
-1. **Technical dependencies (highest weight):** Issues that other issues depend on get `priority:critical` or `priority:high`. Identify dependency chains: DB schema before API, API before frontend, shared libs before consumers, infrastructure before application.
+1. **Technical dependencies (highest weight):** Issues that other issues depend on get `priority::critical` or `priority::high`. Identify dependency chains: DB schema before API, API before frontend, shared libs before consumers, infrastructure before application.
 
-2. **Business value (medium weight):** Issues the user marked as core MVP features in the PRD get `priority:high`. Nice-to-haves and polish items get `priority:medium` or `priority:low`.
+2. **Business value (medium weight):** Issues the user marked as core MVP features in the PRD get `priority::high`. Nice-to-haves and polish items get `priority::medium` or `priority::low`.
 
 3. **Risk (tiebreaker) — Impact × Risk 2×2 triage:** Classify each issue by Impact (high/low) and Risk (high/low) before applying the bump:
    - **High-Impact + Low-Risk → Implement.** Proceed directly; apply the one-level priority bump from the tiebreaker rule.
@@ -387,7 +387,7 @@ Score each issue using three factors:
    - **Low-Impact + High-Risk → Reject.** Do not create an issue for this candidate; note the rejection rationale in the PRD's Risks & Dependencies section instead.
 
 Assign labels from the standard taxonomy:
-- `priority:critical` / `priority:high` / `priority:medium` / `priority:low`
+- `priority::critical` / `priority::high` / `priority::medium` / `priority::low`
 - `type:feature` / `type:enhancement` / `type:bug` / `type:chore` / `type:discovery`
 - `status:ready`
 - `area:<inferred from content>` (e.g., `area:api`, `area:frontend`, `area:infra`)
@@ -422,8 +422,8 @@ If user selects "Adjust priorities" or "Remove issues", handle the adjustments i
 For each approved issue:
 
 1. Create via VCS CLI using comma-separated labels in a single `--label` flag:
-   - **GitLab**: `glab issue create --title "[Plan] <title>" --label "type:feature,priority:high,status:ready" --description "<body>"`
-   - **GitHub**: `gh issue create --title "[Plan] <title>" --label "type:feature,priority:high,status:ready" --body "<body>"`
+   - **GitLab**: `glab issue create --title "[Plan] <title>" --label "type:feature,priority::high,status:ready" --description "<body>"`
+   - **GitHub**: `gh issue create --title "[Plan] <title>" --label "type:feature,priority::high,status:ready" --body "<body>"`
 2. Brief pause (1s) between creations for rate limiting
 3. After all issues are created, set dependency links:
    - **GitLab**: use `glab api` to set `blocks`/`is-blocked-by` relations. On HTTP 403 (non-Premium/Ultimate): `relates_to` + body-ordering-note fallback — see gitlab-ops SKILL.md § "Issue Linking (`blocks` / `is_blocked_by`)".

package/skills/plan/mode-feature.md

@@ -111,9 +111,9 @@ Source: PRD Section 3 (Acceptance Criteria).
 
 Apply this scoring:
 
-1. **Technical dependencies** — Issues that block other issues get `priority:critical` or `priority:high`. DB before API, API before UI, shared before consumers.
-2. **Core acceptance criteria** — Issues covering primary happy-path scenarios get `priority:high`.
-3. **Edge cases / nice-to-haves** — Defensive scenarios, error handling, optional behaviors get `priority:medium` or `priority:low`.
+1. **Technical dependencies** — Issues that block other issues get `priority::critical` or `priority::high`. DB before API, API before UI, shared before consumers.
+2. **Core acceptance criteria** — Issues covering primary happy-path scenarios get `priority::high`.
+3. **Edge cases / nice-to-haves** — Defensive scenarios, error handling, optional behaviors get `priority::medium` or `priority::low`.
 4. **Risk factor — Impact × Risk 2×2 triage:** Classify by Impact (high/low) × Risk (high/low): **High-Impact + Low-Risk → Implement** (bump priority up one level); **High-Impact + High-Risk → Experiment** (smallest spike first); **Low-Impact + Low-Risk → Defer** (backlog, no issue in this set); **Low-Impact + High-Risk → Reject** (no issue — note rationale in § Risks & Dependencies). Full quadrant definitions: `SKILL.md` § 6.2 Auto-Prioritize.
 
 ### Labels
@@ -121,7 +121,7 @@ Apply this scoring:
 Apply per gitlab-ops skill label taxonomy:
 
 - **Type:** `type:feature` for new capabilities, `type:enhancement` for extensions of existing features.
-- **Priority:** `priority:critical` / `priority:high` / `priority:medium` / `priority:low` from auto-prioritize above.
+- **Priority:** `priority::critical` / `priority::high` / `priority::medium` / `priority::low` from auto-prioritize above.
 - **Area:** Infer from affected code paths (e.g., `area:api`, `area:frontend`, `area:infra`).
 - **Appetite:** Map from Wave 1 Q5 scope answer (`appetite:1w`, `appetite:2w`, `appetite:6w`).