fix(docs): correct eight stale or wrong facts from the held re-audit rows

.changes/architecture/fix-d27-stale-facts-3e522788.md

@@ -0,0 +1,7 @@
+---
+bump: patch
+---
+
+### Fixed
+
+- Corrected stated facts that had gone stale or were wrong, each checked against its current source.

.changes/code-tidying/fix-d27-stale-facts-5c5a241a.md

@@ -0,0 +1,7 @@
+---
+bump: patch
+---
+
+### Fixed
+
+- Corrected stated facts that had gone stale or were wrong, each checked against its current source.

.changes/event-storming/fix-d27-stale-facts-07d51153.md

@@ -0,0 +1,7 @@
+---
+bump: patch
+---
+
+### Fixed
+
+- Corrected stated facts that had gone stale or were wrong, each checked against its current source.

.changes/machine-health/fix-d27-stale-facts-75212561.md

@@ -0,0 +1,7 @@
+---
+bump: patch
+---
+
+### Fixed
+
+- Corrected stated facts that had gone stale or were wrong, each checked against its current source.

.changes/session-flow/fix-d27-stale-facts-63949c65.md

@@ -0,0 +1,7 @@
+---
+bump: patch
+---
+
+### Fixed
+
+- Corrected stated facts that had gone stale or were wrong, each checked against its current source.

.changes/work-items/fix-d27-stale-facts-8b97b159.md

@@ -0,0 +1,7 @@
+---
+bump: patch
+---
+
+### Fixed
+
+- Corrected stated facts that had gone stale or were wrong, each checked against its current source.

plugins/architecture/skills/improve/actions/deepening.md

@@ -76,7 +76,7 @@ Verification can be a second cheap read-only subagent pass or inline reproductio
 
 **Re-badge first.** Before rendering, map each surviving candidate's scan `confidence` to its `recommendation` badge (`strong` → `Strong`, `worth-exploring` → `Worth exploring`, `speculative` → `Speculative`), then re-badge against the two acceptance heuristics below (deletion-test acceptance form, two-adapter rule) and the Phase 1.5 verification result. Scan-time confidence is an input, not the final badge. A candidate whose `shallow-signal` failed to reproduce, or whose value rests on a one-adapter abstraction, cannot carry `Strong`. **Promotion closes the same gate:** if re-badging lifts a candidate the scan rated below `strong` up to `Strong`, apply the Phase 1.5 reproduction to its `shallow-signal` *before* it carries the badge. A `Strong` claim reaches the report reproduced no matter which way the badge was reached, so the Phase 1.5 guarantee holds across both the original strong set and any promotions.
 
-The report is one self-contained HTML file under the OS temp directory, one per run, created via a secure temp-file primitive so the path is unpredictable and permissions are restrictive. On Unix/Linux, create a run directory with `mktemp -d "${TMPDIR:-/tmp}/deepening-review-XXXXXX"` and write `report.html` inside it. Carry the temp root in the positional template, the one form GNU and BSD `mktemp` accept identically, since `-p`/`--tmpdir`/`-t` differ between the dialects and a bare relative template silently creates the file in the **current directory**, the consumer's repository. Keep the `XXXXXX` placeholders **trailing**. BSD `mktemp` (macOS) substitutes only trailing Xs, so an extension after them is not portable. A directory plus a fixed filename is the form that keeps the Xs trailing while still yielding a meaningful `.html` name. On Windows, use a user-scoped temp under `%LOCALAPPDATA%\Temp` or equivalent. Resolve that one path deterministically. Never branch on an injected scratchpad path or `CLAUDE_JOB_DIR`. Show it to the user through the platform's opener: `start` (Windows), `open` (macOS) or `xdg-open` (Linux), each given the path. Report the absolute path. Do **not** delete the file after reporting: the path is the delivery mechanism and must stay readable for the user to open. It outlives the invocation and nothing documented reclaims the OS temp tree on a schedule, which is why one run writes one file and never an accumulating tree.
+The report is one self-contained HTML file under the OS temp directory, one per run, created via a secure temp-file primitive so the path is unpredictable and permissions are restrictive. On Unix/Linux, create a run directory with `mktemp -d "${TMPDIR:-/tmp}/deepening-review-XXXXXX"` and write `report.html` inside it. Carry the temp root in the positional template, the one form GNU and BSD `mktemp` accept identically, since `-p`/`--tmpdir`/`-t` differ between the dialects and a bare relative template silently creates the file in the **current directory**, the consumer's repository. Keep the `XXXXXX` placeholders **trailing**. BSD `mktemp` (macOS) substitutes only trailing Xs, so an extension after them is not portable. A directory plus a fixed filename is the form that keeps the Xs trailing while still yielding a meaningful `.html` name. On Windows, use a user-scoped temp under `%LOCALAPPDATA%\Temp` or equivalent. Resolve that one path deterministically. Never branch on an injected scratchpad path or `CLAUDE_JOB_DIR`. Show it to the user through the platform's opener: `start` (Windows), `open` (macOS) or `xdg-open` (Linux), each given the path. Report the absolute path. Do **not** delete the file after reporting: the path is the delivery mechanism and must stay readable for the user to open. It outlives the invocation, which is why one run writes one file and never an accumulating tree.
 
 **The rendered-views security baseline governs the report.** The baseline is owned by `docs/contracts/rendered-views/README.md` ("Security baseline") in the marketplace repository; its rules are repeated here because this skill runs where that file is not on disk. Everything taken from the scanned repository is untrusted data: escape `&`, `<`, `>`, `"`, and `'` in text and attribute positions; never interpolate unescaped content into `<script>` or `<style>`; never build an event-handler attribute from input. The report is self-contained: no external requests, no remote scripts, assets inline. The two additions specific to this report (which strings count as repository-derived, and no `<script>` inside SVG) live in [../research/deepening/html-report.md](../research/deepening/html-report.md). Build layout from an inline `<style>` block; draw diagrams as inline SVG or hand-built HTML/CSS: inline SVG node-and-edge for graph-shaped relationships, hand-built divs for the layer stacks and size bars that a node-and-edge drawing cannot show. <!-- contract-restatement: rendered-views-security-baseline -->
 

plugins/code-tidying/skills/remove-comments/reference/tooling.md

@@ -55,7 +55,7 @@ lands, or a probe row changes status on a machine where it used to pass.
 | tree-sitter-bash 0.25.1 rejects base-N arithmetic (`N#$var` inside `$(( ))`) | ERROR nodes, one spanning a third of `lib/hook-utils.sh`, so `change-shape.py` returns UNPROVABLE for the file against itself and no deletion or rename in it can carry a proof; 35 `.sh` files in this tree carry the form | 2026-09-08 |
 | tree-sitter-powershell 0.26.4 vs `Parser::ParseFile`, on 27,564 lines of real PowerShell (`Provisioning.psm1` 537 KB, `Provisioning.Tests.ps1` 1.0 MB) | the grammar: 33 ERROR + 1 MISSING and 115 ERROR + 172 MISSING, so both files are UNPROVABLE against themselves; the native parser: **0** parse errors on both, in 97 ms and 225 ms | 2026-09-20 |
 | Deleting every comment token by its extent, then comparing the `(Kind, Text)` sequence minus `Comment`/`NewLine` | identical for 1,069 comments in `Provisioning.psm1` and 2,114 in `Provisioning.Tests.ps1`; deleting only the `#Requires` line also leaves the sequence identical, which is why it is kept as its own leaf | 2026-09-20 |
-| PowerShell on the GitHub-hosted runner images, from [`actions/runner-images`](https://github.com/actions/runner-images) `main` | `ubuntu-24.04` 7.6.5 ([Ubuntu2404-Readme.md](https://github.com/actions/runner-images/blob/main/images/ubuntu/Ubuntu2404-Readme.md)), `windows-2025` 7.6.6 ([Windows2025-Readme.md](https://github.com/actions/runner-images/blob/main/images/windows/Windows2025-Readme.md)), `macos-15` 7.6.4 ([macos-15-Readme.md](https://github.com/actions/runner-images/blob/main/images/macos/macos-15-Readme.md)). Only these three were checked; other image labels are unverified. Recheck when a runner-images release changes the PowerShell version in any of the three readmes | 2026-09-21 |
+| PowerShell on the GitHub-hosted runner images, from [`actions/runner-images`](https://github.com/actions/runner-images) `main` | `ubuntu-24.04` 7.6.9 ([Ubuntu2404-Readme.md](https://github.com/actions/runner-images/blob/main/images/ubuntu/Ubuntu2404-Readme.md)), `windows-2025` 7.6.9 ([Windows2025-Readme.md](https://github.com/actions/runner-images/blob/main/images/windows/Windows2025-Readme.md)), `macos-15` 7.6.4 ([macos-15-Readme.md](https://github.com/actions/runner-images/blob/main/images/macos/macos-15-Readme.md)). Only these three were checked; other image labels are unverified. Recheck when a runner-images release changes the PowerShell version in any of the three readmes | 2026-11-11 |
 | `pwsh` 7.6.6 cold start, `-NoProfile -NonInteractive` | 0.50–0.69 s, plus roughly 1.5 s per megabyte of source to tokenize and serialize. A `List.Add` per token instead of an indexed write into a preallocated array costs 3.9 s on the 97k-token file where the indexed write costs 1.0 s, which is why nested string tokens are emitted as a side list rather than inline | 2026-09-21 |
 
 ## What no tool covers

plugins/event-storming/skills/simulation/reference/agentic-simulation.md

@@ -505,7 +505,7 @@ for the tool namespace, color mapping, spacing values, and board setup.
 
 ### Round-Based Orchestration: Following Brandolini's Incremental Phases
 
-Agents can't subscribe to live board changes, because MCP is request/response, not streaming. The realistic pattern is **round-based orchestration**, which maps to Brandolini's Big Picture phases exactly. **Critical: follow the incremental notation and don't dump all building blocks at once.**
+Agents do not subscribe to live board changes; the pattern here is **round-based orchestration**, which maps to Brandolini's Big Picture phases exactly. **Critical: follow the incremental notation and don't dump all building blocks at once.**
 
 **Agent Execution Pattern**
 

plugins/event-storming/skills/simulation/reference/miro-integration.md

@@ -281,7 +281,7 @@ The `miro` plugin's server supports bulk creation (up to 20 items per batch) via
   on rectangle-heavy boards
 - **Bulk limit**: max 20 items per bulk operation
 - **Rate limits**: Miro API has rate limits; space out bulk operations
-- **No real-time collaboration**: MCP operations are request/response, not live collaborative editing
+- **No real-time collaboration**: agents act in rounds, not live collaborative editing
 - **Color approximation**: Miro's sticky colors don't perfectly match physical sticky note colors, but are close enough
 
 ## Gotchas

plugins/machine-health/skills/audit/SKILL.md

@@ -1,5 +1,5 @@
 ---
-description: "Audits local workstation health and emits a findings report: runs OS-specific checks (disk, OS updates, security posture, CISA KEV) from a versioned catalog with trend-aware severity; remediation only when pre-approved. Use when: 'machine health check', 'audit my machine', 'system health', 'workstation status report', or when a scheduled weekly routine fires. Outputs a dated markdown report; updates append-only history state. Windows fully implemented; macOS/Linux scaffolded (reports UNKNOWN and stops)."
+description: "Audits local workstation health and emits a findings report: runs OS-specific checks (disk, OS updates, security posture, CISA KEV) from a versioned catalog with trend-aware severity; remediation only when pre-approved. Use when: 'machine health check', 'audit my machine', 'system health', 'workstation status report', or when the scheduled monthly task fires. Outputs a dated markdown report; updates append-only history state. Windows fully implemented; macOS/Linux scaffolded (reports UNKNOWN and stops)."
 argument-hint: "[weekly|on-demand|first-run] [--dry-run] [--scheduled]"
 user-invocable: true
 disable-model-invocation: false

plugins/session-flow/skills/orchestrate/SKILL.md

@@ -220,19 +220,15 @@ Guidance for the main session once a task needs more than one layer; the export
 because a pasted worker sits inside a tree rather than authoring one.
 
 **A rough anchor for small/medium/large.** Not thresholds to enforce, the judgment still runs on context
-boundaries, not head-count, but our anchor follows the platform's workflow size settings: fewer
-than 5 agents is small, 5 to 9 medium, and 10 or more large. A run large enough to trip the
-platform's large-workflow warning is a size to justify out loud. An order-of-magnitude
-disagreement with this anchor is one to name, not skip. Before a workflow run, read the size
-guideline in force for this session: the platform's default differs by plan, and the guideline
-the session sets is the one Claude receives, whatever this anchor says.
-
-- **Pointer**: for the workflow size guideline and its defaults, see
+boundaries, not head-count, but our anchor is the platform's workflow size guideline values,
+read live. A run large enough to trip the platform's large-workflow warning is a size to justify
+out loud. An order-of-magnitude disagreement with this anchor is one to name, not skip. Before a
+workflow run, read the size guideline in force for this session: the guideline the session sets
+is the one Claude receives, whatever this anchor says.
+
+- **Pointer**: for the size guideline values and their defaults, see
   <https://code.claude.com/docs/en/workflows#set-a-size-guideline>; for the large-workflow
   warning, see <https://code.claude.com/docs/en/workflows#cost>.
-- **As of**: 2026-10-18
-- **Recheck trigger**: that page changes a size-guideline agent count, a default guideline, or the
-  threshold its large-workflow warning fires at.
 
 **The top of the tree owns the loop, not the work.** Its context is the scarcest in the run,
 everything that enters it stays for the rest of the session. So it holds the objective, the

plugins/session-flow/skills/workflow/context/philosophy.md

@@ -20,7 +20,8 @@ work.
 
 ## Task tracking
 
-For non-trivial work (3+ stages), create tasks at the START, update status as you go. Tasks make
+For non-trivial work (3+ stages), when this session has the task tools, create tasks at the START
+and update status as you go (`SKILL.md` step 5 covers sessions without them). Tasks make
 progress visible; for state that must survive `/clear`, use the durable checklist or a `/session-flow:handoff`
 save-point. In-memory tasks do not persist.
 

plugins/work-items/skills/track/actions/due.md

@@ -36,7 +36,7 @@ fi
 
 `<project root>` is the literal path [`tracker-seam.md`](../../../reference/tracker-seam.md) "Project root" resolves, in its own Bash call before this snippet and each later one in this file.
 
-For days-overdue computation, calculate `(today - next_due)` in days. jq lacks date arithmetic, so compute this when presenting the table (parse the ISO dates and subtract).
+For days-overdue computation, calculate `(today - next_due)` in days when presenting the table (parse the ISO dates and subtract).
 
 1. **Cross-reference with open items.** For each due recurring item, check if one already exists
    (adapter: "List items", `--label <resolved recurring-maintenance label>`, with bodies, bare

plugins/work-items/skills/track/actions/start.md

@@ -46,7 +46,7 @@ Claim a work item through the seam (assignee + lease record).
 
 1. **Suggest branch name.** The branch name carries the item, so `/source-control:pull-request create` can resolve it from the branch and write the bound adapter's link line. The token it carries is the adapter's `branch_ref` for the claimed `<id>` (`42` on GitHub, `ENG-123` on Linear): `bash "${CLAUDE_PLUGIN_ROOT}/tools/work-item-tracker/work-item-tracker.sh" change-link <id>`, field `.branch_ref` (`${CLAUDE_PLUGIN_ROOT}/tools/work-item-tracker/CONTRACT.md` "Change links"). `<ref>` below is that value. On exit `6` (an adapter that predates `change-link`), use the number after `#` in `<id>`. The agent NEVER runs `git checkout` itself; it emits the command for the user.
 
-   **Derive the branch `<type>` vocabulary** (the commit-layer prefix: `feat`/`fix`/`chore`/…) from the item's **issue type**. Prefer the native GitHub Issue Type when present: `Bug` → `fix`, `Feature` → `feat`, `Task` → `chore`. Fall back to a `type:` label (personal / non-org repos, or a not-yet-migrated org item). The coarse long-form labels map like the native types: `type: bug` → `fix`, `type: feature` → `feat`, `type: task` → `chore`. A legacy commit-style label maps by Conventional Commits priority: `feat > fix > refactor > docs > chore > test > build > perf`, first match wins, strip the `type:` prefix. Default to `chore` when neither is present.
+   **Derive the branch `<type>` vocabulary** (the commit-layer prefix: `feat`/`fix`/`chore`/…) from the item's **issue type**. Prefer the native GitHub Issue Type when present: `Bug` → `fix`, `Feature` → `feat`, `Task` → `chore`. Fall back to a `type:` label (personal / non-org repos, or a not-yet-migrated org item). The coarse long-form labels map like the native types: `type: bug` → `fix`, `type: feature` → `feat`, `type: task` → `chore`. A legacy commit-style label maps by this priority: `feat > fix > refactor > docs > chore > test > build > perf`, first match wins, strip the `type:` prefix. Default to `chore` when neither is present.
 
    **Derive `<slug>`** from the item title: lowercase, replace non-alphanumeric runs with `-`, trim leading/trailing `-`, cap 40 chars.