session-orchestrator 3.16.0 → 3.19.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

@@ -261,6 +261,7 @@ 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
+   - `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

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
@@ -272,7 +280,7 @@ Relates to #ORIGINAL_IID
 ## [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 +310,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/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

@@ -0,0 +1,97 @@
+---
+name: npm-publish
+user-invocable: true
+model: sonnet
+description: Use when publishing this package to npm — a version release (npm publish), verifying the registry/pi.dev listing, or diagnosing npm auth failures (E403 2FA/token errors). Token-based flow via NPM_TOKEN in .env.local with a temp userconfig, leakage-gate greps before every publish, post-publish verification and marker/badge upkeep. Trigger on "publish to npm", "npm release", "E403 publish error".
+---
+
+# npm-publish — Token-based publish runbook
+
+> Companion to `docs/distribution/npm-publish-checklist.md` (the original 7-step operator runbook). This skill adds the token-auth mechanics and the failure-mode diagnosis learned during the v3.16.0 first publish (2026-07-19).
+
+## Why this skill exists
+
+npm requires 2FA **or** a granular access token with "Bypass 2FA" for every publish (policy active since 2025; legacy tokens were removed Nov 2025 — only granular tokens exist). The failure mode is confusing: `npm publish` fails with **E403 and NO OTP prompt** when the account either has no 2FA enrolled or the supplied token lacks the bypass flag. Three dead ends verified empirically: plain `npm publish` (E403), `--auth-type=web` (no web flow exists for publish), PTY-forced publish (same E403). The ONLY non-interactive path is a correctly-configured granular token.
+
+## Token requirements (all four mandatory)
+
+Create at https://www.npmjs.com/settings/<user>/tokens → Generate New Token → **Granular Access Token**:
+
+1. **Permissions: Read and write** (Packages and scopes).
+2. **Packages: "All packages"** for a FIRST publish (the package does not exist yet, so per-package selection cannot include it). After the first publish, re-create scoped to the single package — least privilege.
+3. **"Bypass two-factor authentication (2FA)" enabled** — this is the checkbox whose absence produces the E403-without-prompt. npm shows a red security warning here and recommends Trusted Publishing for CI/CD; for interactive operator-assisted releases the short-lived bypass token is acceptable.
+4. **Short expiration** — write tokens default to 7 days (90 max). Take the default.
+
+## Auth resolution order
+
+1. `NPM_TOKEN` in `.env.local` at the repo root (gitignored — verify with `git check-ignore .env.local` before writing; also confirm no `.env` pattern in the `files` whitelist of package.json).
+2. Interactive fallback: operator runs `npm publish --access public` in a real terminal (only works when account 2FA is enrolled — OTP prompt appears).
+
+**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.
+
+## 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)
+npm view session-orchestrator version
+
+# 2. Leakage gate — every grep MUST print 0 (from docs/distribution/npm-publish-checklist.md)
+npm pack --dry-run 2>&1 | grep -cE "npm notice.* tests/"
+npm pack --dry-run 2>&1 | grep -c "npm notice.*\.orchestrator/"
+npm pack --dry-run 2>&1 | grep -cE "npm notice.*[[:space:]]\.claude/"
+npm pack --dry-run 2>&1 | grep -c "npm notice.*\.github/"
+npm pack --dry-run 2>&1 | grep -c "node_modules"
+npm pack --dry-run 2>&1 | grep -ci "\.env"
+npm pack --dry-run 2>&1 | grep -ci "owner\.yaml"
+
+# 3. Publish via temp userconfig (never a persistent npmrc)
+NPM_TOKEN=$(grep '^NPM_TOKEN=' .env.local | cut -d= -f2-)
+TMPRC=$(mktemp) && printf '//registry.npmjs.org/:_authToken=%s\n' "$NPM_TOKEN" > "$TMPRC" && chmod 600 "$TMPRC"
+npm publish --access public --userconfig "$TMPRC"; rm "$TMPRC"
+
+# 4. Verify
+npm view session-orchestrator version   # must print the new version
+```
+
+Success marker: `+ session-orchestrator@<version>` on the publish output.
+
+## Post-publish checklist
+
+1. **Verify registry**: `npm view session-orchestrator version dist.unpackedSize keywords` — `pi-package` keyword must be present.
+2. **pi.dev gallery**: indexing is asynchronous — check https://pi.dev/packages later; do not block on it.
+3. **Marker upkeep** (first publish only — done in v3.16.0): README install matrix + npm badge, `site/index.html` install section, `docs/pi-setup.md` availability paragraph.
+4. **Rotate/delete the token** at https://www.npmjs.com/settings/<user>/tokens once the release is done — especially if the token value ever transited chat, a screenshot, or any log. A token pasted into a conversation is burned: rotate immediately after use.
+5. Update the release issue / CHANGELOG if the publish was part of a tracked release.
+
+## Failure-mode table
+
+| Symptom | Cause | Fix |
+|---|---|---|
+| `E403 ... Two-factor authentication or granular access token with bypass 2fa enabled is required` — no OTP prompt | Account has no 2FA enrolled AND token (if any) lacks Bypass-2FA | Create granular token with all four requirements above, or enroll 2FA |
+| Same E403 despite a fresh token | Token created without the Bypass-2FA checkbox, or Read-only, or package-scoped on a first publish | Re-create: RW + All packages + Bypass-2FA |
+| `E404` on `npm view` after publish | Registry propagation (rare, seconds) or publish actually failed | Re-check the publish output for `+ <name>@<version>` |
+| `ENEEDAUTH` | No login/token at all | Token flow above, or `npm login` |
+| OTP prompt appears but flow is non-interactive (`!`-prefix, script) | No TTY for the prompt | Use the token flow, or a real terminal |
+
+## Security invariants
+
+- `.env.local` is gitignored AND absent from the npm `files` whitelist — verify both before writing a token into it.
+- Temp userconfig: `chmod 600`, deleted immediately after publish.
+- The leakage gate runs before EVERY publish, not only the first.
+- npm's own recommendation for unattended CI/CD is **Trusted Publishing** (OIDC) — evaluate it if publishing ever moves into CI (ref: https://docs.npmjs.com/about-access-tokens).

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`).
 

package/skills/plan/mode-new.md

@@ -235,10 +235,10 @@ Score each issue using three factors:
 
 1. **Technical dependencies (highest weight):**
    - DB schema before API, API before frontend, shared libs before consumers.
-   - Issues that block others → `priority:critical` or `priority:high`.
+   - Issues that block others → `priority::critical` or `priority::high`.
 2. **Business value (medium weight):**
-   - Core MVP features → `priority:high`.
-   - Nice-to-haves → `priority:medium` or `priority:low`.
+   - Core MVP features → `priority::high`.
+   - Nice-to-haves → `priority::medium` or `priority::low`.
 3. **Risk (tiebreaker):**
    - Issues with identified risks from PRD Section 7 → bump up one level.
 
@@ -249,12 +249,12 @@ Use taxonomy from `setup-gitlab-groups.sh`:
 **Priority mapping for VCS labels:**
 | Categorization | VCS Label |
 |---|---|
-| P0 (critical path, blocking) | `priority:critical` |
-| P1 (high impact, needed soon) | `priority:high` |
-| P2 (medium, can wait) | `priority:medium` |
-| P3 (nice-to-have) | `priority:low` |
+| P0 (critical path, blocking) | `priority::critical` |
+| P1 (high impact, needed soon) | `priority::high` |
+| P2 (medium, can wait) | `priority::medium` |
+| P3 (nice-to-have) | `priority::low` |
 
-Always use the `priority:<level>` format in VCS CLI commands, not P0/P1/P2/P3.
+Always use the `priority::<level>` format in VCS CLI commands, not P0/P1/P2/P3.
 
 - **type:** feature, enhancement, bug, chore, docs
 - **status:** `status:ready`
@@ -275,11 +275,11 @@ Use AskUserQuestion to present the full issue structure:
 ```bash
 # Create epic
 glab issue create --title "$EPIC_TITLE" --description "$EPIC_DESC" \
-  --label "type:epic,priority:$PRIORITY" --milestone "$MILESTONE"
+  --label "type:epic,priority::$PRIORITY" --milestone "$MILESTONE"
 
 # Create sub-issues
 glab issue create --title "$ISSUE_TITLE" --description "$ISSUE_DESC" \
-  --label "type:feature,priority:$PRIORITY,status:ready,area:$AREA,appetite:$APPETITE"
+  --label "type:feature,priority::$PRIORITY,status:ready,area:$AREA,appetite:$APPETITE"
 ```
 
 ### Step 6: Set dependency links

package/skills/plan/mode-retro.md

@@ -225,7 +225,7 @@ Before Phase 3.2, satisfy the PRD Commit Gate — see `SKILL.md` § Phase 5.5 (H
 
 Create one VCS issue per agreed improvement from Wave 2:
 - **Title**: `[Retro] <action description>`
-- **Labels**: `type:enhancement`, `priority:<from ranking>`, `area:<inferred>`
+- **Labels**: `type:enhancement`, `priority::<from ranking>`, `area:<inferred>`
 - **Description**: action, impact, effort, link to retro document
 - Create via VCS CLI (per gitlab-ops skill)
 

package/skills/quality-gates/SKILL.md

@@ -109,7 +109,7 @@ Commands:
 4. Check changed files for debug artifacts: `console.log`, `debugger`, `TODO: remove`.
 
 Behavior: BLOCKING. Do not commit if any check fails. Fix quick issues (<2 min) inline.
-For anything longer, create a `priority:high` issue and proceed without committing the
+For anything longer, create a `priority::high` issue and proceed without committing the
 affected files.
 
 > **Broken-Window cross-reference (#730/H5):** a Full-Gate PASS that ships with a documented exception (echo-stub, WARN-lint, overridden finding) feeds session-end Phase 2.6 — see `skills/session-end/SKILL.md § Phase 2.6`.

package/skills/reconcile/SKILL.md

@@ -35,6 +35,16 @@ any file is written. Advisory-only — rules are NEVER auto-applied.
 - **Engine never writes `.claude/rules/`.** `runReconcile` computes proposals and records
   them in the idempotency sidecar only. The only module that writes `.claude/rules/` is
   `writer.mjs`, and only AFTER the operator approves proposals via AUQ.
+- **The candidate store belongs to `mergeCandidates` — nothing else writes it.**
+  `.orchestrator/runtime/reconcile-candidates.jsonl` is a mutable work-queue whose only
+  sanctioned writer is `mergeCandidates` (`scripts/lib/reconcile/idempotency.mjs`); it is
+  not a scratch pad, and no report, analysis run, or agent may append to it by hand. A
+  hand-written record there corrupts downstream readers — the session-start reconcile nudge
+  banner derives "last run" from `created_at`, so a foreign-shaped record makes a non-empty
+  store report *no reconcile run on record*. Candidate analyses and dry-run reports write
+  their findings to `docs/reconcile/<date>-<topic>.md`, never into the store. (Since
+  2026-07-31 a read-side shape guard drops records lacking `learning_key`/`created_at` and
+  `mergeCandidates` reports the count as `skipped` — that guard is a backstop, not a licence.)
 - **Same pipeline as session-end Phase 3.6.8.** This skill uses the identical engine and
   writer seams as the automatic session-end reconciliation phase — operator experience is
   consistent, and any fixes to the engine benefit both paths.
@@ -76,6 +86,7 @@ CONFIDENCE_FLOOR=$(echo "$CONFIG" | jq -r '.reconcile["confidence-floor"] // 0.5
 RECONCILE_MODE=$(echo "$CONFIG"   | jq -r '.reconcile.mode // "warn"')
 MIN_RULE_DAYS=$(echo "$CONFIG"    | jq -r '.reconcile["min-rule-days"] // 7')
 MIN_INSIGHT_CHARS=$(echo "$CONFIG" | jq -r '.reconcile["min-insight-chars"] // 24')
+MAX_PROPOSALS_PER_RUN=$(echo "$CONFIG" | jq -r '.reconcile["max-proposals-per-run"] // 10')
 ```
 
 When `RULE_EXPIRY_DAYS` is empty, pass `ruleExpiryDays: undefined` to `runReconcile` so the engine uses its per-type TTL. Defaults when the `reconcile` block is absent or a field is missing:
@@ -86,6 +97,8 @@ When `RULE_EXPIRY_DAYS` is empty, pass `ruleExpiryDays: undefined` to `runReconc
   near-dead or already-elapsed natural expiry never produces a born-dead rule (issue #741.1).
 - `min-insight-chars`: 24 — opt-in minimum insight length gating the eligibility
   placeholder-insight check (issue #741.2).
+- `max-proposals-per-run`: 10 — volume brake (issue #900 D); the engine sorts eligible
+  learnings by confidence DESC and proposes at most this many per run.
 
 Note: `reconcile.enabled` is intentionally NOT checked — this on-demand command always runs.
 
@@ -119,6 +132,7 @@ const { proposals, rejected, summary, error } = await runReconcile({
   ruleExpiryDays: RULE_EXPIRY_DAYS,   // empty → undefined → engine per-type TTL
   minRuleDays: MIN_RULE_DAYS,         // default 7 — floors a near-dead expires-at
   minInsightChars: MIN_INSIGHT_CHARS, // default 24 — opt-in placeholder-insight length gate
+  maxProposalsPerRun: MAX_PROPOSALS_PER_RUN, // default 10 — volume brake (issue #900 D)
   now: new Date(),
   dryRun: DRY_RUN,     // true → engine touches no disk (no idempotency sidecar write)
 });
@@ -163,7 +177,10 @@ List `rejected[].reason` and exit.
 
 **Only when `DRY_RUN=true`.**
 
-Print the proposals in a readable table. Do NOT write the sidecar, do NOT render an AUQ.
+Print the proposals in a readable table. Do NOT write the sidecar, do NOT render an AUQ, and
+do NOT write candidates into `.orchestrator/runtime/reconcile-candidates.jsonl` — that store
+is `mergeCandidates`' alone (see Posture Contract). A dry-run write-up belongs in
+`docs/reconcile/`.
 
 ```
 ## Reconcile — Dry Run  (N proposals, M rejected)
@@ -307,9 +324,9 @@ If `written === 0` and `approved.length === 0`:
   silently swallow failures.
 - **ALWAYS** present proposals in batches of ≤4 via AUQ multiSelect — mirrors session-end
   3.6.3 / 3.6.8 and keeps the operator prompt readable.
-- **ALWAYS** honour `confidence-floor`, `rule-expiry-days`, `min-rule-days`, and
-  `min-insight-chars` from Session Config `reconcile` block — the engine reads these, but
-  the skill must pass them explicitly.
+- **ALWAYS** honour `confidence-floor`, `rule-expiry-days`, `min-rule-days`,
+  `min-insight-chars`, and `max-proposals-per-run` from Session Config `reconcile` block —
+  the engine reads these, but the skill must pass them explicitly.
 
 ## Anti-Patterns