jorgex-stack 1.2.0 → 1.2.1

package/README.md

@@ -99,7 +99,7 @@ Programmatic mode does **not** provide:
 
 Browser automation is opt-in and explicit. The legacy `agent-browser` integration has been removed; rely on the two surfaces below.
 
-- **Playwright CLI** (recommended): `@playwright/cli@0.1.17` plus a vendored skill that ships pinned with the stack. The skill is loaded on demand, contributes no permanent MCP schemas, and declares `allowed-tools: Bash(playwright-cli:*)` only (no `Bash(pnpm:*)`). This is the skill's declaration, not a security boundary: effective permissions still come from the adapter/runtime, and OpenCode/full-bash may expose broader Bash or other capabilities. See [docs/references/browser-automation.md](docs/references/browser-automation.md) for the full lifecycle, the security profile and troubleshooting.
+- **Playwright CLI** (recommended): `@playwright/cli@0.1.18` plus a vendored skill that ships pinned with the stack. The skill is loaded on demand, contributes no permanent MCP schemas, and declares `allowed-tools: Bash(playwright-cli:*)` only (no `Bash(pnpm:*)`). This is the skill's declaration, not a security boundary: effective permissions still come from the adapter/runtime, and OpenCode/full-bash may expose broader Bash or other capabilities. See [docs/references/browser-automation.md](docs/references/browser-automation.md) for the full lifecycle, the security profile and troubleshooting.
 - **Chrome DevTools MCP** (advanced diagnostics, opt-in): exposes ~29 tools and ~5,800–7,700 tokens of schemas in full mode. Disabled by default, selected per runtime, version-pinned, and launched with a fixed argv `pnpm dlx chrome-devtools-mcp@1.6.0 --isolated --redact-network-headers --no-performance-crux --no-usage-statistics`. `--isolated` starts Chrome with an ephemeral, isolated profile that is deleted when Chrome closes (no persistent dedicated profile, no shared cookies/extensions/sessions with your personal Chrome); `--redact-network-headers` redacts sensitive headers in captured network traffic, but not request/response bodies, which may contain tokens or PII. Avoid authenticated sessions or sensitive data, or disable network capture manually outside the stack when needed. `--no-performance-crux` disables CrUX reporting; `--no-usage-statistics` disables telemetry. `--slim` and Playwright MCP are intentionally excluded.
 
 Setup that respects the zero-secrets, pnpm-only and explicit-consent rules:
@@ -116,13 +116,13 @@ pnpm dlx jorgex-stack install --devtools
 pnpm dlx jorgex-stack install --no-devtools
 ```
 
-Under the hood, `--playwright` runs two `pnpm` argv-only plans back to back: `pnpm add --global @playwright/cli@0.1.17` (the package) and then `pnpm dlx @playwright/cli@0.1.17 install-browser` (the browser binary cache). Removal is `pnpm remove --global @playwright/cli` (no version suffix). If installation fails, the error identifies the failed phase — global package, browser download, or preference persistence — and recommends `jorgex-stack install --playwright`; the preference is not marked enabled unless the complete plan succeeds.
+Under the hood, `--playwright` runs two `pnpm` argv-only plans back to back: `pnpm add --global @playwright/cli@0.1.18` (the package) and then `pnpm dlx @playwright/cli@0.1.18 install-browser` (the browser binary cache). Removal is `pnpm remove --global @playwright/cli` (no version suffix). If installation fails, the error identifies the failed phase — global package, browser download, or preference persistence — and recommends `jorgex-stack install --playwright`; the preference is not marked enabled unless the complete plan succeeds.
 
 Daily operation:
 
 - `sync` reconciles configuration without installing global tools or browsers; if Playwright is enabled but the binary or browser cache is `missing`, it warns and points to `install --playwright`; if the cache is `unreadable`, the warning includes its resolved path and filesystem error code. The cache probe retains the path for both states and an error code when the filesystem provides one. Under `--target-dir`, `sync`/`install`/`uninstall` never read or write the real browser state (`~/.jorgex-stack/playwright-cli.json` and `~/.jorgex-stack/devtools-mcp.json` are untouched, `detectPlaywrightCli()` is not called, no MCP ownership is persisted).
 - `doctor` reports the Playwright CLI state (`disabled`, `healthy`, `missing:package`, `missing:browser`, `unreadable`, `broken`, `outdated`) without opening sites or repairing state. An `unreadable` browser cache includes its exact path and filesystem error code so permissions or another local cause can be investigated. If either preference file is corrupt, doctor prints the exact path and the remedy (`Corrige o borra ese archivo antes de reintentar`) before any other browser check; in that case `install`/`uninstall`/`update`/`update --check` will abort with exit 1 until the file is fixed, so the corruption cannot be reconciled destructively.
-- `update --check` only inspects Playwright CLI when its preference is `enabled` (a binary appearing in `PATH` is not consent). It compares the installed version against the approved pin `0.1.17` — it does not consult npm latest, and a Playwright CLI binary-only update does not require `sync` afterwards.
+- `update --check` only inspects Playwright CLI when its preference is `enabled` (a binary appearing in `PATH` is not consent). It compares the installed version against the approved pin `0.1.18` — it does not consult npm latest, and a Playwright CLI binary-only update does not require `sync` afterwards.
 - `uninstall` preserves the global `@playwright/cli` package and all browser data by default; `--remove-playwright` removes the package only (never the browser cache, profiles, cookies, storage state, traces, screenshots or videos). If `pnpm remove --global @playwright/cli` exits non-zero, `uninstall` reports the failure instead of a success outro. For DevTools MCP, ownership is released only after the corresponding unmerge is applied; if no unmerge action is written, the ownership marker is preserved for a later retry.
 - `install`/`sync` also inject (and `disable`/`uninstall` remove) a marked section `<!-- jorgex:browser -->` in `AGENTS.md` (OpenCode, Codex) or `CLAUDE.md` (Claude Code): the section only contains Playwright guidance when its setup succeeded, and DevTools guidance only in the runtimes that selected it; the rest of the file outside the markers is preserved. `--target-dir` never reads the real preferences, so by default no section is emitted in target-dir runs — but explicit flags like `--devtools` simulate the MCP entry (and the corresponding DevTools block of the section) inside the temp target without touching the real global state, and `install --dry-run --playwright` projects the Playwright section into the plan preview without installing anything. If the post-setup reconciliation of the system prompt leaves the section in a partial state, the CLI exits non-zero and recommends `jorgex-stack sync` to repair it; the package and the preference stay installed. See [docs/references/browser-automation.md](docs/references/browser-automation.md) §2.7 for the full lifecycle.
 
@@ -132,7 +132,7 @@ Daily operation:
 
 1. **Stack** (jorgex-stack): detects whether it is a git clone or a global install, then offers an update with confirmation.
 2. **Engram** (binary): detects the installed version and offers an update through the **native channel** (brew -> `go install` -> release URL). Nothing needs to be stopped: as in upstream macOS/Linux, live processes keep using the old version until clients restart; on Windows, the in-use `.exe` is rotated by rename before installation. **Automatic DB backup before updating**. The database and memories are never touched.
-3. **Playwright CLI** (only when explicitly enabled): compares the detected binary with the approved bundle pin and offers to realign it with explicit confirmation. The realignment re-applies **both** plans — `pnpm add --global @playwright/cli@0.1.17` (package) and `pnpm dlx @playwright/cli@0.1.17 install-browser` (browser cache) — and fails closed if either step returns non-zero. The error identifies whether the package-update or browser-download phase failed and recommends `jorgex-stack install --playwright` to retry both; a Playwright update does not require `sync`.
+3. **Playwright CLI** (only when explicitly enabled): compares the detected binary with the approved bundle pin and offers to realign it with explicit confirmation. The realignment re-applies **both** plans — `pnpm add --global @playwright/cli@0.1.18` (package) and `pnpm dlx @playwright/cli@0.1.18 install-browser` (browser cache) — and fails closed if either step returns non-zero. The error identifies whether the package-update or browser-download phase failed and recommends `jorgex-stack install --playwright` to retry both; a Playwright update does not require `sync`.
 4. **Vendored skills** (maintainer only): third-party skills ship **pinned** with the stack version, so the installed package never reaches out to their upstreams. Only when running from a git clone (`pnpm cli update`) does `update` scan the upstreams in `upstreams.json`, download to a temp directory, **show a mandatory diff**, and ask for confirmation. A moved upstream is only a candidate until that review is accepted and a deliberate re-pin is made for a future release; it is never treated as an accepted official update automatically. Skills with local changes (`modified: true`) warn and require double confirmation.
 
 Usage:

package/dist/cli.js

@@ -1654,7 +1654,7 @@ import { execFileSync as execFileSync2 } from "child_process";
 var PLAYWRIGHT_CLI = {
   packageName: "@playwright/cli",
   bin: "playwright-cli",
-  version: "0.1.17",
+  version: "0.1.18",
   browserInstallAction: "install-browser"
 };
 var PNPM_GLOBAL_BIN_REMEDY = "Ejecuta 'pnpm setup', abre una terminal nueva y reintenta. El stack no modifica PNPM_HOME ni PATH.";
@@ -3286,7 +3286,7 @@ async function runInteractiveUpdate(localVersion, yes, dryRun = false, includeBr
       updateItems.push({
         value: "playwright-cli",
         label: `Playwright CLI: ${current} \u2192 pin aprobado`,
-        hint: "pnpm add --global @playwright/cli@0.1.17"
+        hint: "pnpm add --global @playwright/cli@0.1.18"
       });
     }
   }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "jorgex-stack",
-  "version": "1.2.0",
+  "version": "1.2.1",
   "description": "Harness multi-agente portable: instala la config JorgeX (agentes, skills, hooks, Engram, MCPs) en Claude Code, Codex CLI y OpenCode",
   "type": "module",
   "license": "MIT",

package/stack/skills/diagnose/SKILL.md

@@ -9,9 +9,15 @@ A discipline for hard bugs. Skip phases only when explicitly justified.
 
 When exploring the codebase, use the project's domain glossary to get a clear mental model of the relevant modules, and check ADRs in the area you're touching.
 
+## Redact
+
+This skill has you show commands, outputs and captured artifacts. **Redact every secret first**: write `<REDACTED>` in its place. Build loops against env vars, so the credential stays in the environment rather than in what you show. Captured artifacts can carry auth headers: quote only the lines that carry the signal.
+
+If the redacted output is not enough to diagnose the bug, say so and ask the user.
+
 ## Phase 1 — Build a feedback loop
 
-**This is the skill.** Everything else is mechanical. If you have a fast, deterministic, agent-runnable pass/fail signal for the bug, you will find the cause — bisection, hypothesis-testing, and instrumentation all just consume that signal. If you don't have one, no amount of staring at code will save you.
+**This is the skill.** Everything else is mechanical. If you have a **tight**, fast, deterministic, agent-runnable pass/fail signal for the bug — one that goes red on _this_ bug — you will find the cause; bisection, hypothesis-testing, and instrumentation all just consume that signal. If you don't have one, no amount of staring at code will save you.
 
 Spend disproportionate effort here. **Be aggressive. Be creative. Refuse to give up.**
 
@@ -30,15 +36,15 @@ Spend disproportionate effort here. **Be aggressive. Be creative. Refuse to give
 
 Build the right feedback loop, and the bug is 90% fixed.
 
-### Iterate on the loop itself
+### Tighten the loop
 
-Treat the loop as a product. Once you have _a_ loop, ask:
+Treat the loop as a product. Once you have _a_ loop, **tighten it**:
 
 - Can I make it faster? (Cache setup, skip unrelated init, narrow the test scope.)
 - Can I make the signal sharper? (Assert on the specific symptom, not "didn't crash".)
 - Can I make it more deterministic? (Pin time, seed RNG, isolate filesystem, freeze network.)
 
-A 30-second flaky loop is barely better than no loop. A 2-second deterministic loop is a debugging superpower.
+A 30-second flaky loop is barely better than no loop; a 2-second deterministic one is tight, a debugging superpower.
 
 ### Non-deterministic bugs
 
@@ -46,11 +52,20 @@ The goal is not a clean repro but a **higher reproduction rate**. Loop the trigg
 
 ### When you genuinely cannot build a loop
 
-Stop and say so explicitly. List what you tried. Ask the user for: (a) access to whatever environment reproduces it, (b) a captured artifact (HAR file, log dump, core dump, screen recording with timestamps), or (c) permission to add temporary production instrumentation. Do **not** proceed to hypothesise without a loop.
+Stop and say so explicitly. List what you tried. Ask the user for: (a) access to whatever environment reproduces it, (b) a **redacted** captured artifact (HAR file, log dump, core dump, screen recording with timestamps), or (c) permission to add temporary production instrumentation. Do **not** proceed to hypothesise without a loop.
+
+### Completion criterion: a tight loop that goes red
+
+Phase 1 is done when the loop is **tight** and **red-capable**: you can name **one command** (a script path, a test invocation, a curl) that you have **already run at least once** (show the invocation and its output, redacted), and that is:
 
-Do not proceed to Phase 2 until you have a loop you believe in.
+- [ ] **Red-capable**: it drives the actual bug code path and asserts the **user's exact symptom**, so it can go red on this bug and green once fixed. Not "runs without erroring"; it must be able to **catch this specific bug**.
+- [ ] **Deterministic**: same verdict every run (flaky bugs: a pinned, high reproduction rate, per above).
+- [ ] **Fast**: seconds, not minutes.
+- [ ] **Agent-runnable**: you can run it unattended; a human in the loop only via `scripts/hitl-loop.template.sh`.
 
-## Phase 2 — Reproduce
+If you catch yourself reading code to build a theory before this command exists, **stop: jumping straight to a hypothesis is the exact failure this skill prevents.** No red-capable command, no Phase 2.
+
+## Phase 2 — Reproduce + minimise
 
 Run the loop. Watch the bug appear.
 
@@ -60,7 +75,15 @@ Confirm:
 - [ ] The failure is reproducible across multiple runs (or, for non-deterministic bugs, reproducible at a high enough rate to debug against).
 - [ ] You have captured the exact symptom (error message, wrong output, slow timing) so later phases can verify the fix actually addresses it.
 
-Do not proceed until you reproduce the bug.
+### Minimise
+
+Once it's red, shrink the repro to the **smallest scenario that still goes red**. Cut inputs, callers, config, data, and steps **one at a time**, re-running the loop after each cut, and keep only what's load-bearing for the failure.
+
+Why bother: a minimal repro shrinks the hypothesis space in Phase 3 (fewer moving parts left to suspect) and becomes the clean regression test in Phase 5.
+
+Done when **every remaining element is load-bearing**: removing any one of them makes the loop go green.
+
+Do not proceed until you have reproduced **and minimised**.
 
 ## Phase 3 — Hypothesise
 

package/stack/skills/mcp-builder/LICENSE.txt

@@ -187,7 +187,7 @@
       same "printed page" as the copyright notice for easier
       identification within third-party archives.
 
-   Copyright [yyyy] [name of copyright owner]
+   Copyright 2026 Anthropic, PBC.
 
    Licensed under the Apache License, Version 2.0 (the "License");
    you may not use this file except in compliance with the License.
@@ -199,4 +199,4 @@
    distributed under the License is distributed on an "AS IS" BASIS,
    WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    See the License for the specific language governing permissions and
-   limitations under the License.
+   limitations under the License.

package/stack/skills/playwright-cli/SKILL.md

@@ -345,13 +345,13 @@ playwright-cli kill-all
 If the global `playwright-cli` command is not available, use the pinned release with pnpm:
 
 ```bash
-pnpm dlx @playwright/cli@0.1.17 --version
+pnpm dlx @playwright/cli@0.1.18 --version
 ```
 
 For a global command, install the pinned release:
 
 ```bash
-pnpm add --global @playwright/cli@0.1.17
+pnpm add --global @playwright/cli@0.1.18
 ```
 
 ## Example: Form submission

package/stack/skills/playwright-cli/references/test-generation.md

@@ -289,12 +289,12 @@ Goal: take a spec file and produce Playwright test files. Optionally update the
 
 ### 2.2 Generate one scenario
 
-For each target scenario, in sequence (never in parallel — scenarios share the seed session):
+For each target scenario, run the CLI actions in sequence within its own seed session. Never run actions in parallel within one attached session; a seed session is single-threaded.
 
 ```bash
 PLAYWRIGHT_HTML_OPEN=never pnpm exec playwright test <seed-file> --debug=cli   # background
 playwright-cli attach tw-XXXX
-# resume
+playwright-cli resume
 ```
 
 **Do not** just open the app url with playwright-cli, always go through the test to capture any custom setup done there.
@@ -348,7 +348,7 @@ Rules:
 
 ### 2.3 Generate multiple scenarios
 
-Loop 2.2 over the targeted scenarios one at a time, restarting the seed between each so every test starts from a clean page. This is safe to parallelise due to unique generated session names - just make sure each test run is stopped.
+Loop 2.2 over the targeted scenarios, restarting the seed between each so every test starts from a clean page. Scenarios may run in parallel only when each has its own seed process and unique generated session name; never share a session or attach two scenario flows to the same seed. When isolation is uncertain, run scenarios serially. Stop every test run before moving on.
 
 ### 2.4 Run generated tests
 

package/stack/skills/skill-creator/LICENSE.txt

@@ -187,7 +187,7 @@
       same "printed page" as the copyright notice for easier
       identification within third-party archives.
 
-   Copyright [yyyy] [name of copyright owner]
+   Copyright 2026 Anthropic, PBC.
 
    Licensed under the Apache License, Version 2.0 (the "License");
    you may not use this file except in compliance with the License.
@@ -199,4 +199,4 @@
    distributed under the License is distributed on an "AS IS" BASIS,
    WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    See the License for the specific language governing permissions and
-   limitations under the License.
+   limitations under the License.

package/stack/skills/supabase/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: supabase
-description: "Use when doing ANY task involving Supabase. Triggers: Supabase products (Database, Auth, Edge Functions, Realtime, Storage, Vectors, Cron, Queues); client libraries and SSR integrations (supabase-js, @supabase/ssr) in Next.js, React, SvelteKit, Astro, Remix; auth issues (login, logout, sessions, JWT, cookies, getSession, getUser, getClaims, RLS); Supabase CLI or MCP server; schema changes, migrations, security audits, Postgres extensions (pg_graphql, pg_cron, pg_vector)."
+description: "Use for any Supabase task: Database, Auth, Edge Functions, Realtime, Storage, Vectors, Cron, Queues, clients, CLI/MCP, schema/migrations/declarative schemas, RLS/security, debugging, errors, troubleshooting, or logs."
 metadata:
   author: supabase
   version: "0.1.2"
@@ -88,7 +88,7 @@ supabase <group> <command> --help  # Flags for a specific command
 
 - `supabase db query` requires **CLI v2.79.0+** → use MCP `execute_sql` or `psql` as fallback
 - `supabase db advisors` requires **CLI v2.81.3+** → use MCP `get_advisors` as fallback
-- When you need a new migration SQL file, **always** create it with `supabase migration new <name>` first. Never invent a migration filename or rely on memory for the expected format.
+- In imperative migration projects, create new hand-authored migration files with `supabase migration new <name>` first. Never invent a migration filename or rely on memory for the expected format. Declarative schema projects generate migrations from `supabase/schemas/`; see "Making and Committing Schema Changes" below.
 
 **Version check and upgrade:** Run `supabase --version` to check. For CLI changelogs and version-specific features, consult the [CLI documentation](https://supabase.com/docs/reference/cli/introduction) or [GitHub releases](https://github.com/supabase/cli/releases).
 
@@ -118,16 +118,42 @@ Before implementing any Supabase feature, find the relevant documentation. Use t
 
 ## Making and Committing Schema Changes
 
-**To make schema changes, use `execute_sql` (MCP) or `supabase db query` (CLI).** These run SQL directly on the database without creating migration history entries, so you can iterate freely and generate a clean migration when ready.
+Choose one project-level schema workflow before editing. Do not mix declarative schema files and hand-authored migrations for the same change.
 
-Do NOT use `apply_migration` to change a local database schema — it writes a migration history entry on every call, which means you can't iterate, and `supabase db diff` / `supabase db pull` will produce empty or conflicting diffs. If you use it, you'll be stuck with whatever SQL you passed on the first try.
+### Option A: Declarative schemas
 
-**When ready to commit** your changes to a migration file:
+Use this when `supabase/schemas/` exists or `[db.migrations].schema_paths` is configured. The schema files are the source of truth; do not make the change directly in Studio, the SQL editor, or through `execute_sql`.
 
-1. **Run advisors** → `supabase db advisors` (CLI v2.81.3+) or MCP `get_advisors`. Fix any issues.
-2. **Review the Security Checklist above** if your changes involve views, functions, triggers, or storage.
-3. **Generate the migration** → `supabase db pull <descriptive-name> --local --yes`
-4. **Verify** → `supabase migration list --local`
+1. Edit the desired state in `supabase/schemas/`.
+2. Generate a migration from that state → `supabase db diff -f <descriptive-name>`.
+3. Review the generated migration for one incremental change and any destructive SQL.
+4. Verify the full chain → `supabase db reset` (or apply pending migrations to a running local database with `supabase migration up`).
+5. Commit the schema files and generated migration together.
+
+`supabase db diff` does not read the live database. Changes made directly to a database are not captured by the declarative diff. DML and other documented schema-diff limitations belong in a versioned imperative migration instead. See the [Declarative database schemas guide](https://supabase.com/docs/guides/local-development/declarative-database-schemas).
+
+### Option B: Imperative migrations
+
+Use this when the project does not use declarative schemas.
+
+1. Create the migration → `supabase migration new <descriptive-name>`.
+2. Add the SQL to the generated file; never invent a migration filename or rely on memory for its format.
+3. Verify the full chain → `supabase db reset` (or use `supabase migration up` when applying pending migrations to a running local database).
+4. Run advisors, review the Security Checklist above when applicable, and commit the migration.
+
+For an interactive experiment, target the local development database explicitly (for example, use `supabase db query` in the local project). Do not use the stack's default remote Supabase MCP for local iteration. If a local DDL experiment is the intended change, capture it with `supabase db diff -f <descriptive-name>` and review the migration; DML must be written explicitly into a versioned imperative migration because schema diff does not capture it. Otherwise reset or discard the experiment before starting the migration. Do not use `supabase db pull` for local changes. `supabase db pull` is for pulling a linked remote schema into a local migration.
+
+Do NOT use `apply_migration` to change a local database schema — it writes a migration history entry on every call, which prevents iterative work and can leave the migration history inconsistent. If you use it, you are stuck with whatever SQL you passed on the first try.
+
+When a migration is ready, `supabase db advisors` (CLI v2.81.3+) or MCP `get_advisors` can check the resulting database. Fix findings before committing, then use `supabase migration list --local` when you need to compare local and remote migration history.
+
+## Debugging
+
+When you get an error on a Supabase-related request, for example an error code from the Supabase REST API, Postgres database, or PostgREST, an empty result, getting blocked by RLS unexpectedly, or an error from a Supabase service like Auth, Realtime, Edge Functions, or Storage, you **must** fetch Supabase's [Monitoring and Debugging](https://supabase.com/docs/guides/monitoring-and-debugging.md) documentation before diagnosing or proposing a fix, rather than working from memory. The same docs also cover performance optimizations, such as slow queries and missing indexes.
+
+If the documentation or MCP is unavailable (offline or unauthenticated), explicitly label the result as an **offline fallback**. Use only checked-in guidance, local project evidence, and commands confirmed with `supabase --help`; do not guess version-specific behavior or run an unverified mutation. If the available evidence is insufficient, stop and ask for the missing context.
+
+Before inspecting, querying, or sharing logs and errors, redact API keys, access tokens, JWTs, cookies, authorization headers, connection strings, and sensitive request or user payloads. Never print or paste secrets.
 
 ## Reference Guides
 

package/stack/skills/supabase-postgres-best-practices/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: supabase-postgres-best-practices
-description: Postgres performance optimization and best practices from Supabase. Use this skill when writing, reviewing, or optimizing Postgres queries, schema designs, or database configurations.
+description: "Use for Postgres work: schema design, migrations, declarative schemas, RLS, queries, performance, indexes, locks, triggers, functions, jobs, pgvector, imports/restores, or diagnosing timeouts and connection issues."
 license: MIT
 metadata:
   author: supabase

package/stack/skills/tdd/SKILL.md

@@ -47,6 +47,10 @@ Use the cheapest seam that can fail for the real regression:
 
 “Integration-style” is not inherently stronger. A broad test full of mocks may be weaker than a focused rule test, while a regex over SQL text is weaker than executing the database behavior it claims to protect.
 
+## Anti-pattern: tautological tests
+
+Do not let an assertion recompute the expected value the way the code does (`expect(add(a, b)).toBe(a + b)`, a snapshot derived by hand the same way, or a constant asserted equal to itself). It passes by construction and can never disagree with the code. Expected values must come from an independent source of truth: a known-good literal, a worked example, or the spec.
+
 ## Anti-pattern: horizontal slices
 
 Do not write all tests first and then all implementation. This outruns what has been learned and encourages tests of imagined shapes.

package/stack/skills/to-issues/SKILL.md

@@ -19,6 +19,8 @@ Work from whatever is already in the conversation context. If the user passes an
 
 If you have not already explored the codebase, do so to understand the current state of the code. Issue titles and descriptions should use the project's domain glossary vocabulary, and respect ADRs in the area you're touching.
 
+Look for opportunities to prefactor the code to make the implementation easier. If a prefactoring is useful but optional, record it explicitly in the plan; if selected, publish it as its own issue before the slices that depend on it. "Make the change easy, then make the easy change."
+
 ### 3. Draft vertical slices
 
 Break the plan into **tracer bullet** issues. Each issue is a thin vertical slice that cuts through ALL integration layers end-to-end, NOT a horizontal slice of one layer.
@@ -28,9 +30,21 @@ Slices may be 'HITL' or 'AFK'. HITL slices require human interaction, such as an
 <vertical-slice-rules>
 - Each slice delivers a narrow but COMPLETE path through every layer (schema, API, UI, tests)
 - A completed slice is demoable or verifiable on its own
+- Each slice is sized to fit in a single fresh context window
 - Prefer many thin slices over few thick ones
+- Any selected prefactoring should be completed first and block the dependent slices
 </vertical-slice-rules>
 
+Give each issue its **blocking edges**: the other issues that must complete before it can start. An issue with no blockers can start immediately. Keep the same edges in the project plan and the issue tracker.
+
+**Wide refactors are the exception to vertical slicing.** A **wide refactor** is one mechanical change (for example, renaming a column or retyping a shared symbol) whose **blast radius** fans across the codebase, so a single edit breaks many call sites at once and no vertical slice can land green. Sequence it as **expand–contract**:
+
+1. **Expand:** add the new form beside the old so nothing breaks.
+2. **Migrate:** move call sites in batches sized by blast radius (for example, per package or directory), each as its own issue blocked by the expand issue, keeping the project green batch to batch while the old form still exists.
+3. **Contract:** delete the old form once no caller remains, in an issue blocked by every migration batch.
+
+When even the migration batches cannot stay green alone, keep the sequence but use an integration branch that all batches block, followed by a final integrate-and-verify issue; green is promised only there.
+
 ### 4. Quiz the user
 
 Present the proposed breakdown as a numbered list. For each slice, show:
@@ -43,7 +57,7 @@ Present the proposed breakdown as a numbered list. For each slice, show:
 Ask the user:
 
 - Does the granularity feel right? (too coarse / too fine)
-- Are the dependency relationships correct?
+- Are the blocking edges correct: does each slice only depend on issues that genuinely gate it?
 - Should any slices be merged or split further?
 - Are the correct slices marked as HITL and AFK?
 

package/upstreams.json

@@ -14,49 +14,51 @@
       "path": "skills/playwright-cli",
       "package": "@playwright/cli",
       "binary": "playwright-cli",
-      "version": "0.1.17",
-      "commit": "793cfb32572733cbcb401e6f28d05a7a914ce408",
+      "version": "0.1.18",
+      "commit": "2f85a94b7b885dbf4a5d34462f253a8746a690c9",
       "license": "Apache-2.0",
-      "modified": true
+      "modified": true,
+      "note": "bundle release firmado 0.1.18 en ca196c297169a494ee5517584883eada60dc8d0e; el pin commit es el HEAD revisado del repo"
     },
     "deploy-to-vercel": {
       "source": "github:vercel-labs/agent-skills",
       "path": "skills/deploy-to-vercel",
       "version": "3.0.0",
-      "commit": "f8a72b9603728bb92a217a879b7e62e43ad76c81",
+      "commit": "dd089a8c752c966dee8bf0f27cb625ba193ffd9e",
       "modified": true,
       "note": "por diseño empaqueta el proyecto entero (tarball) y lo sube a un endpoint de Vercel para desplegarlo; excluye .env/.env.*/.git/node_modules"
     },
     "diagnose": {
       "source": "github:mattpocock/skills",
       "path": "skills/engineering/diagnosing-bugs",
-      "commit": "694fa30311e02c2639942308513555e61ee84a6f",
-      "note": "upstream renombró la carpeta diagnose → diagnosing-bugs; mantenemos el nombre local 'diagnose'. El pin sigue en la última revisión aceptada hasta hacer diff y re-pin deliberado del contenido nuevo."
+      "commit": "5b15a47f2d7150f545fbcacbfe381787fc0230dc",
+      "modified": true,
+      "note": "upstream renombró la carpeta diagnose → diagnosing-bugs; mantenemos el nombre y las adaptaciones locales sobre el HEAD revisado"
     },
     "find-skills": {
       "source": "github:vercel-labs/skills",
       "path": "skills/find-skills",
-      "commit": "be0dd25b4a8665894a56f45ef582cc02ca802c39",
+      "commit": "435076e78988e1e6ec40d00b0b1d76bdbbc5419a",
       "modified": true,
       "note": "la copia vendorizada se limita a descubrir skills; no acepta ni ejecuta instalación, actualización o inicialización de contenido upstream"
     },
     "mcp-builder": {
       "source": "github:anthropics/skills",
       "path": "skills/mcp-builder",
-      "commit": "57546260929473d4e0d1c1bb75297be2fdfa1949",
+      "commit": "3b3fad96af16a10759d930941b4520ba0c40edae",
       "license": "Apache-2.0",
       "modified": true
     },
     "react-doctor": {
       "source": "github:millionco/react-doctor",
       "path": "skills/react-doctor",
-      "commit": "a48fb06ffbe7221655e18529fcc954ecae17a22f",
+      "commit": "e183c3519010599d929ed14d99a18bf1f8f8a44c",
       "modified": true
     },
     "skill-creator": {
       "source": "github:anthropics/skills",
       "path": "skills/skill-creator",
-      "commit": "57546260929473d4e0d1c1bb75297be2fdfa1949",
+      "commit": "3b3fad96af16a10759d930941b4520ba0c40edae",
       "license": "Apache-2.0",
       "modified": true
     },
@@ -64,35 +66,35 @@
       "source": "github:supabase/agent-skills",
       "path": "skills/supabase",
       "version": "0.1.2",
-      "commit": "1356046015476711a769601079262b5635929427",
+      "commit": "8331f910845103c08d51f6ca1d86ebb7d1f745e3",
       "modified": true
     },
     "supabase-postgres-best-practices": {
       "source": "github:supabase/agent-skills",
       "path": "skills/supabase-postgres-best-practices",
-      "commit": "1356046015476711a769601079262b5635929427",
+      "commit": "8331f910845103c08d51f6ca1d86ebb7d1f745e3",
       "license": "MIT",
       "modified": true
     },
     "tdd": {
       "source": "github:mattpocock/skills",
       "path": "skills/engineering/tdd",
-      "commit": "694fa30311e02c2639942308513555e61ee84a6f",
+      "commit": "5b15a47f2d7150f545fbcacbfe381787fc0230dc",
       "modified": true
     },
     "to-issues": {
       "source": "github:mattpocock/skills",
       "path": "skills/engineering/to-tickets",
-      "commit": "694fa30311e02c2639942308513555e61ee84a6f",
+      "commit": "5b15a47f2d7150f545fbcacbfe381787fc0230dc",
       "modified": true,
-      "note": "upstream renombró to-issues → to-tickets; conservamos el nombre local to-issues y el pin de la última revisión aceptada hasta comparar y aceptar contenido nuevo deliberadamente"
+      "note": "upstream renombró to-issues → to-tickets; conservamos el nombre y las adaptaciones locales sobre el HEAD revisado"
     },
     "to-prd": {
       "source": "github:mattpocock/skills",
       "path": "skills/engineering/to-spec",
-      "commit": "694fa30311e02c2639942308513555e61ee84a6f",
+      "commit": "5b15a47f2d7150f545fbcacbfe381787fc0230dc",
       "modified": true,
-      "note": "upstream renombró to-prd → to-spec; conservamos el nombre local to-prd y el pin de la última revisión aceptada hasta comparar y aceptar contenido nuevo deliberadamente"
+      "note": "upstream renombró to-prd → to-spec; conservamos el contrato D9 v2 local sobre el HEAD revisado"
     }
   }
 }