Refresh PStack workflows without model changes

CHANGELOG.md

@@ -4,6 +4,15 @@ summary: Timeline of guardrail helper changes mirrored from Sweetistics and rela
 
 # Changelog
 
+## 2026-10-04: PStack workflow refresh
+- Ported upstream PStack 0.15.9 workflows through `e43c7ee26e`, preserving every local model, effort, panel, and model-routing override.
+- Added `correct`, `benchmark-checklist`, and `principle-explain-the-number`; strengthened Architect ownership/API checks and schema-first TypeScript validation examples.
+- Defaulted new assignments and fix rounds to fresh agents; moved autopilot verification to code-ready rounds, tracked child recovery, and adapted hourly quiet audit ticks to Codex heartbeat scheduling.
+- Tightened Swarm SHA/method receipts, PR briefing sections, rebase/CI verdict reuse, and append-only run-aware decision logs; applied upstream prompt trimming.
+- Restored upstream's worktree isolation and checkout-recovery policy in Opening a PR; translated `Task` to Codex's `collaboration.spawn_agent`.
+- Dry-run fixes: restore upstream's todolist wording instead of requiring an unavailable `update_plan` tool; name Codex's `/goal` correctly in Bug fix.
+- Landing checks: retain the plan checker's existing fenced-code handling and required checklist boxes; upstream skill wording and model policy unchanged.
+
 ## 2026-09-29: GPT-6.1 Sol routing
 - Correct the remaining Autoreview prose summary to GPT-6.1 Sol xhigh, matching its executable and documented defaults.
 - Move hardest tasks and Reflect judgment, divergent, and synthesis roles to GPT-6.1 Sol high; align their setup and fallback defaults.

docs/upstream-mined.md

@@ -7,9 +7,12 @@
 - 2026-09-03 targeted PStack pass: mined `cursor/plugins` `pstack` at `b9ddc83c32972210b8a94d389130713e8eed346e`; ported 21 principle skills, Poteto Mode, and supporting workflows with Codex collaboration, permission, transcript, and model-routing adaptations. Global marker unchanged because this was a separate upstream.
 - 2026-09-08 targeted PStack refresh: reconciled `cursor/plugins` `pstack` through `23a56e2dac2efd54788056db8eced26e371d7b5e` (including `73f8be4`). The existing Codex playbooks already contained the applicable forge-neutral PR, stack, regression-lane, and patch-id wording. Omitted Cursor-only `paths` and `disable-model-invocation` frontmatter because the Codex skill validator rejects those keys. Adapted upstream Fable 5.1 routing to the local role policy: Astra medium for judgment and primary review, optional Fable 5.1 max for a second review, Sol high for implementation, Luna high for discovery and procedural verification. Added `typescript-best-practices` with its upstream patterns and added a fail-closed Codex adaptation of `make-bot-ui`. Skipped Cursor plugin manifest and guide changes plus `setup-pstack`; the latter installs Cursor-specific model rules and has no Codex counterpart.
 - 2026-09-13 PStack bump: regenerated at `cursor/plugins` `889ec4b` (bug-fix, perf-issue, hillclimb on the fast code model upstream, `gpt-5.6-sol` here). Mined `michael-denyer/pstack-claude` v0.9.29 for its hardened `poteto-mode/scripts` (watch-pr pagination and head-SHA integrity, serialized orch store, NUL-safe worktree audit) and adopted six `cursor-team-kit` skills it imports (`fix-ci`, `fix-merge-conflicts`, `get-pr-comments`, `make-pr-easy-to-review`, `thermo-nuclear-code-quality-review`, `what-did-i-get-done`). Not adopted from that port: its Claude-native skill bodies, `codex-tools.md` runtime mapping, standalone `babysit` skill, merge-ready-only autopilots, and Claude-only interrogate panel.
+- 2026-10-04 PStack workflow refresh: ported `cursor/plugins` `pstack` through `e43c7ee26e0038c6c1fa8380dd34ce86ff94cb2a` (0.15.9), from `5bf2b1544d`. Added `correct`, `benchmark-checklist`, and `principle-explain-the-number`; adopted architecture red flags, fresh-agent defaults, autopilot round/recovery changes, quiet hourly audits, SHA/method receipts, PR headings, schema-first examples, append-only log audits, and prompt trimming. Preserved all local models, efforts, panels, aliases, and fallback policy; skipped upstream model/config changes. Codex adaptations: hourly heartbeat scheduling for `/loop 1h`, collaboration agents and local skill/control paths, Codex rollouts, separate model/effort validation, and supported skill metadata. Kept the existing orch/watcher helpers from `pstack-claude`; aligned the changed log/plan helpers to upstream with Codex plan markers. Cursor plugin packaging and its standalone guide remain upstream-only. Restored upstream wording verbatim except required Codex substitutions and unchanged model policy; omitted local per-skill licenses and source banners. Global marker unchanged.
 - 2026-09-14 PStack setup refresh: ported `cursor/plugins` `pstack` through `5bf2b1544d` (reasoning-budget choice in `setup-pstack`), adapting upstream model-slug effort changes to Codex's separate `model` and `reasoning_effort` fields. Global marker unchanged because this was a separate upstream.
 - 2026-09-12 PStack regeneration: mined `cursor/plugins` `pstack` at `f5bdd68d`; every ported skill, playbook, reference, and script is now generated from upstream by `port-upstream.py` (minimal Codex substitutions, kept-ours list for environment rules, privacy appends for the `why` source playbooks). Ported the last upstream-only skills (`automate-me`, `setup-pstack`) and the `cursor-team-kit` `control-cli`/`control-ui`. Still upstream wording, awaiting a decision: Bugbot, Origin, Graphite, `/loop` as a periodic tick, and the `why` MCP sources Bram does not run.
 
+The 2026-10-11 landing retains the local plan checker's fenced-code handling and required checklist boxes after regression proof. Upstream skill wording and model policy remain unchanged.
+
 ## Flow (repeat per pass)
 
 ```bash

skills/architect/SKILL.md

@@ -9,7 +9,7 @@ Design before implementing. Sketch types, function signatures, class shapes, and
 
 ## Start
 
-Call `update_plan` with one entry per phase before starting.
+Open a todolist with one entry per phase before starting.
 
 1. Ground
 2. Sketch
@@ -33,7 +33,7 @@ Use `architect runners` from `${CODEX_HOME:-$HOME/.codex}/skills/poteto-mode/ref
 
 Design it three times. Require three structurally distinct candidates before synthesis, one from each configured Architect runner, even when the first looks sufficient. This is the **exhaust-the-design-space** principle skill made concrete. Whole-shape alternatives, not point fixes inside one shape.
 
-Screen every candidate against [`references/design-red-flags.md`](references/design-red-flags.md) before synthesis. Reject or revise shallow modules, information leakage, temporal decomposition, and pass-through methods.
+Screen every candidate against [`references/design-red-flags.md`](references/design-red-flags.md) before synthesis. Assume the next contributor is an agent that sees only the files it opened, copies the nearest example, and takes the shortest path that compiles. Prefer the design where a change that looks right from one file is right for the whole repo.
 
 Compare viable candidates on interface depth. Prefer the design that hides more complexity behind a smaller, simpler public surface. A rich interface can keep call chains short by concentrating capability instead of scattering it across layers.
 

skills/architect/references/design-red-flags.md

@@ -31,3 +31,27 @@ Group code around domain knowledge and ownership. Methods that run at different
 A pass-through method forwards the same arguments to another method with the same shape. It adds a layer without hiding complexity.
 
 Remove it or move responsibility to the module that can complete the operation. Keep a forwarding boundary only when it adds policy, adaptation, or a distinct abstraction.
+
+## Split ownership
+
+More than one module writes the same state or keeps its own copy of it. An agent that edits one writer can't see the others, so their rules diverge.
+
+Give each piece of state one owner. Other modules read it or ask the owner to change it.
+
+## Two ways to do one task
+
+The design supports more than one way to do the same task. An agent copies whichever way it finds first, so every way keeps gaining callers.
+
+Keep one way. Move callers off the others and delete them in the same change.
+
+## Importable internals
+
+A caller can import a module's internals. An agent takes the shortest path that compiles, so it imports them directly and they become part of the interface.
+
+Make internals unreachable from outside the module, so an import from outside fails the build.
+
+## Hand-synced list
+
+Two or more places list the same items, and adding an item means editing every list. An agent that sees one list updates only that one.
+
+Keep one list and derive the others from it. If a list can't be derived, make the build fail when the lists disagree.

skills/benchmark-checklist/SKILL.md

@@ -0,0 +1,38 @@
+---
+name: benchmark-checklist
+description: "Vet a perf measurement (limiter, tuning, limits, errors, repeatability, relevance, and whether the work happened) before you report or act on it. Use when you run a benchmark or report a speedup or regression you measured."
+---
+
+# Benchmark checklist
+
+Use this when you produce a performance number: a PR's before and after, a regression claim, a hillclimb harness, or a library or config choice. [Explain the Number](../principle-explain-the-number/SKILL.md) says why. Answer each question below with evidence from a run, not from a guess about the code.
+
+For a quick ballpark the user asked for, one run is enough. Still check questions 4 and 7, and say that it is one run. Skip the rest unless that run looks wrong. A choice between options is never a ballpark.
+
+## Before you run anything
+
+- Write down the claim you expect to make, in the words you would ship ("export is 30% faster at p50 on the 60k-row dataset"). The questions test that sentence.
+- Read the measurement script. Note what it times, what it counts, and what it ignores.
+- Check the load average with `uptime` and the core count with `nproc`. If the machine is busy, find out what is running. If you cannot stop it, interleave the sides so both see the same noise, and say so in the report.
+
+## The questions
+
+1. **Why not double?** Name the limiter. Profile in a run you do not report, because profilers and tracers slow the work down. Use CPU per process (`top`, `pidstat`), a profiler for the runtime (`node --cpu-prof`, `py-spy`, `perf`), I/O wait, and syscall counts (`strace -c` on Linux). Then map the hot spot to source. Watch the load generator too. If it saturates first, you measured the load generator. If a change did not move the number, the limiter explains why, so find it before you call the change useless.
+2. **Was it tuned?** Run every side the way production runs it: release builds, production flags and env, batching and transaction settings, connection pools, caches as warm or cold as production sees them, and the same versions and data. If one side runs on defaults, you compared configurations, not implementations. A limiter that is a setting, such as a commit per row, a debug build, or a missing index, means that side is untuned. Tune it and measure again before you pick a winner. If you cannot tune it, do not pick a winner from that run. Narrowing the claim to the code as it ships today does not fix this when the user is choosing what to adopt, because they adopt the option, not today's settings.
+3. **Did it break limits?** Do the arithmetic. Compare bytes per second with disk and network bandwidth, and operations per second times the cost per operation with the cores you have. Compare the time saved with the time the changed piece took. Removing a piece that takes 10% of the run can make the run at most about 11% faster. A result past a limit means the run measured something other than the work, such as a cache, a no-op, or a bug.
+4. **Did it error?** Count failures and non-success responses, and check that the outputs are correct, not just present. Errors behave differently from successes. Rejections are often fast, and timeouts and retries are slow. If the script does not count errors, add the count.
+5. **Does it reproduce?** Run each side at least 5 times, and alternate the sides (A, B, A, B, and so on) so that warmup, lazy initialization, caches, and drift do not favor one side. Report the median and the range. Treat a gap smaller than the run-to-run variation as no measurable difference. When the call is close, use a rank-sum test or the harness's own statistics.
+6. **Does it matter?** Next to any micro result, measure the end-to-end path a user waits on, with realistic data sizes and concurrency. Report the micro result as a share of the whole. A helper that takes 1% of a request can make the request at most 1% faster, however fast the helper gets.
+7. **Did it even happen?** Confirm the work ran inside the timed region. The request reached the server, the rows were written, the bytes were read, and the code used the result. Lazy code (generators nobody iterates, promises nobody awaits, results the JIT can discard) and timeouts all produce numbers for work that never happened.
+
+## Report
+
+- Lead with the verdict: faster, slower, no measurable difference, or inconclusive.
+- Give the number with its unit, the run count, the range, and the limiter. For example, "p50 41 ms → 33 ms, median of 7 runs per side, range 32 to 35 ms after, bound by JSON parsing on one core."
+- Call the verdict inconclusive when you claim a difference but cannot name the limiter, when a side ran untuned, or when you could not check questions 4 and 7. Name the gap.
+- Keep a PR body to one primary number, per the **Opening a PR** playbook. Put the runs, the range, and the limiter evidence in a linked artifact or a notes file.
+
+## How this fits the other perf material
+
+- The **Perf issue** playbook finds and fixes slowness, and the performance mantras in its step 2 generate the fixes. This skill vets its baseline before the playbook plans from it, and every number after that.
+- The **Hillclimb** playbook loops on one metric. This skill vets its harness before the harness is frozen. The frozen harness then prints error and work counts, so each keep-or-revert checks questions 4 and 7 for free.

skills/benchmark-checklist/agents/openai.yaml

@@ -0,0 +1,2 @@
+policy:
+  allow_implicit_invocation: false

skills/blast-radius/SKILL.md

@@ -25,22 +25,22 @@ For each fact the change's safety depends on, get it as far down this list as is
 4. You ran it. A script or test that calls the real code and fails loud if you're wrong.
 5. You reproduced it in the running app.
 
-Any safety fact you can't get to step 4, say so. Don't write it up as settled. Step 4 is usually one small script that imports the same library the app ships and calls the exact function you're worried about.
+Step 4 is usually one small script that imports the same library the app ships and calls the exact function you're worried about.
 
 ## Steps
 
 1. Read the change. The diff, the symbols it adds, changes, and deletes, and what it now does differently, including the part the diff doesn't spell out. Use `why` step 2 to pull the PR and commits.
 2. Find the one fact it's safe because of. Most changes that look risky are safe because of a single fact, like "this call only drops already-dead cache entries and does nothing else". Find that fact. If it holds, most risky cases are cleared at once. Spend your time here, not on a long list of maybes.
 3. Look where grep stops. Read the source of the library you call, and check its pinned version and any local patch. Work out when things run: microtasks, unmount and teardown, Solid versus React. Follow what a symbol search misses: the JSON an API returns, a DB column, a wire format, another language reading the same bytes, a feature flag, code three hops downstream.
 4. Be honest about each risk. Give it a real chance of happening and a real cost if it does. Keep the risks you confirmed. List the ones you checked and cleared separately. Same rules as `why`. Cite a real `file:line`, a search that finds nothing is still an answer, and never make up a caller or an API.
-5. Prove the one fact. Write a script or test that runs the real code, run it, and paste what happened. If you can't prove it cheaply, mark it unproven. Don't overstate.
+5. Prove the one fact. Write a script or test that runs the real code, run it, and paste what happened.
 6. For a big or wide change, run it as an `arena`. Ask several models the same question and merge the answers. Different models catch different real bugs.
 
 ## What to hand back
 
 - **What it does.** What changed, including the part that isn't obvious.
 - **The one fact it's safe because of.** State it, say which step you got it to, and show the proof. If you couldn't prove it, write unproven.
-- **Risks.** Only the real ones. Each names how it breaks, the `file:line`, how likely and how bad, and how to check. Paste the proof for the ones that matter.
+- **Risks.** Each names how it breaks, the `file:line`, how likely and how bad, and how to check. Paste the proof for the ones that matter.
 - **Cleared.** What you checked and why it's fine.
 - **Before you merge.** The cheapest test or repro that catches the real bug, including the script you wrote.