# Plate Plan

> Define or update Plate editor-behavior specs with a pass-gated, evidence-scored plan. Use for behavior law, authority maps, protocol rows, parity gates, research-backed winner shifts, editor chrome contracts, and implementation-roadmap changes.

- Skill: `lofcz/plate-plan` (Agent Skill)
- Install (CLI): `npx skillmds@latest add lofcz/plate-plan`
- Raw SKILL.md: https://api.skillmd.com/api/skills/lofcz/plate-plan/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: lofcz (https://skillmd.com/u/lofcz)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/lofcz/plate-plan

---


# Plate Plan

Handle $ARGUMENTS.

This is the Plate editor-behavior planning and law workflow. It turns behavior
ideas, review findings, or spec drift into:

- a pass-gated plan under `docs/plans/`
- updated editor-behavior law under `docs/editor-behavior/`
- research updates under `docs/research/` when evidence is stale or thin
- a goal-backed plan ledger that stays active until the plan is genuinely ready

Use this when the failure mode is "we keep finding more Plate planning gaps later."

## Use When

- Adding or changing editor behavior law.
- Reviewing current Plate editor-behavior architecture or DX.
- Revising authority/winner maps.
- Adding or splitting interaction families.
- Updating protocol rows, parity gates, roadmap lanes, or reference audits.
- Deciding permanent home for a behavior contract: core, shared package,
  feature package, app/render layer, docs-only, or tests-only.
- Formalizing browser/regression proof for editor behavior.
- The user wants a plan before implementation.

## Do Not Use When

- The user asks for a narrow bug fix without spec work.
- The user asks for a normal code review of a diff.
- The user asks to execute an already accepted Plate Plan.
- The plan already has a passing Plate Plan score, completed pass schedule,
  closed final gates, and the user says to build.

## Hard Policy

- This is a planning/review/spec-law lane first. Do not patch product code unless
  the user explicitly asks for implementation.
- Do not route to external interview or consensus-planning skills. This skill
  owns the plan gate.
- Evidence first. Vibes are not authority.
- Treat silence as a gap, not fake agreement.
- Lock node model and affinity before UX chrome.
- Keep Plate core unopinionated enough for framework use. Opinionated product
  behavior belongs in packages, kits, examples, or docs.
- Prefer the best permanent architecture for performance and DX over the
  nearest current file location.
- If the best answer is a new authority lane, family split, or ownership move,
  say that and plan it.
- A behavior, API, or gate change needs an adoption story. "Cleaner" alone is
  not a justification.
- Intent, outcome, scope, non-goals, and decision boundaries must be explicit
  before the plan can score as ready.
- Major decisions need a decision brief: principles, top drivers, viable
  options, rejected alternatives, and why the chosen option wins.
- Do not let a polished plan self-certify. Scores, verdicts, and keep/drop
  decisions need cited evidence.
- Score is not completion. A passing score with any pending pass, spec-law
  output, verification gate, named next owner, or runnable next action stays
  `pending`.
- The top-level completion status is the lane status, not the current pass
  status. Close a pass with `current_pass_status: complete`; do not use
  top-level `done` unless the whole lane is closed.
- Top-level `done` is legal only in the closure/final-gates pass, after the
  active plan proves every earlier pass-state row is complete or explicitly
  skipped with evidence.
- For current Plate features, parity and protocol matter. For deferred features,
  do not inflate the release gate.
- Run applicable implementation-review lenses instead of trusting generic editor
  intuition: `build-web-apps:shadcn` for UI/editor chrome,
  `vercel-react-best-practices` for React/Next/runtime performance, and
  `react-useeffect` for effects, derived state, subscriptions, and external
  synchronization. Use `performance-oracle` for hot paths, algorithms, memory,
  network, query, bundle, and scalability concerns. Use `tdd` for behavior
  additions, bug fixes, and regression classes that need test-first proof. If a
  lens is skipped, record why.

## Required Artifacts

- Plan file under `docs/plans/`.
- Editor-behavior outputs under `docs/editor-behavior/` when law changes.
- Research updates under `docs/research/` when the evidence lane is stale,
  contradictory, or incomplete.
- Objection ledger in the active plan. If it grows too large, split it to
  `docs/plans/<same-slug>-objection-ledger.md` and link it from the plan.
- Plan deltas from review in the active plan: what changed, what was dropped,
  what was strengthened, and what stayed unchanged with reasons.
- Intent/boundary record in the active plan: intent, outcome, in-scope,
  non-goals, decision boundaries, and unresolved user-decision points.
- Decision brief in the active plan: principles, decision drivers, viable
  options, invalidated alternatives, consequences, and follow-ups.
- Applicable implementation-skill review notes in the active plan: shadcn,
  Vercel React, react-useeffect, performance-oracle, and tdd, each marked
  `applied` or `skipped` with a concrete reason.

## Goal Setup

Before creating or resuming a Plate Plan:

- If a goal tool is available, call `get_goal` first. Call `create_goal()` only
  when no goal exists; repeated `create_goal()` calls fail while a thread goal
  exists.
- Continue under a matching active goal, or resolve a mismatched active goal
  before creating a new one.
- Create the goal around the desired end state, not the execution plan.
- Include constraints, scope, or verification details only when they materially
  change what `done` means.
- Use the goal or user-input tool to ask when the goal would otherwise be
  unclear.
- If no goal tool is available, ask the user to set the goal instead of
  silently skipping goal setup.
- Do not start the planning pass until the goal is set, verified as already
  matching, or the user explicitly resolves the missing-goal path.

Good goal:

```txt
Plate Plan proves the editor-behavior authority, node model, protocol rows,
and proof gates are ready for user review. Execution starts only when the user
accepts the plan and invokes Plate Plan again for that accepted plan.
```

Bad goal:

```txt
Run Plate Plan passes 1 through 9.
```

Default plan path:

```txt
docs/plans/YYYY-MM-DD-plate-plan-review-plan.md
```

Reuse an active plan when the prompt names one, or when the active goal and plan
both point at the same surface and the latest user request is clearly resuming
that lane.

## Read First

Always read only what is relevant, but start from these sources:

1. Latest user request.
2. Current goal state, if a goal tool exists.
3. Active plan under `docs/plans/` if present.
4. [docs/editor-behavior/README.md](docs/editor-behavior/README.md).
5. [docs/editor-behavior/markdown-standards.md](docs/editor-behavior/markdown-standards.md).
6. [docs/editor-behavior/markdown-editing-spec.md](docs/editor-behavior/markdown-editing-spec.md).
7. [docs/editor-behavior/editor-protocol-matrix.md](docs/editor-behavior/editor-protocol-matrix.md).
8. [docs/editor-behavior/markdown-parity-matrix.md](docs/editor-behavior/markdown-parity-matrix.md).
9. [docs/editor-behavior/master-roadmap.md](docs/editor-behavior/master-roadmap.md).
10. [docs/editor-behavior/markdown-editing-reference-audit.md](docs/editor-behavior/markdown-editing-reference-audit.md).
11. [docs/research/README.md](docs/research/README.md), `docs/research/index.md`,
    and `docs/research/log.md` when present.
12. [docs/solutions/best-practices/markdown-editor-reference-audits-must-treat-silence-as-a-gap.md](docs/solutions/best-practices/markdown-editor-reference-audits-must-treat-silence-as-a-gap.md).
13. [docs/solutions/best-practices/editor-behavior-specs-must-lock-node-model-and-affinity-before-ux.md](docs/solutions/best-practices/editor-behavior-specs-must-lock-node-model-and-affinity-before-ux.md).

Read when relevant:

- Intent/boundary pressure when intent, scope, non-goals, or decision
  boundaries are unclear. Record the answer directly in this Plate Plan.
- Steelman pressure when major decisions need maintainer/user objection rows.
  Record the strongest fair objection, tradeoff tension, and adoption answer in
  this Plate Plan.
- High-risk deliberate pressure when a proposal changes public API, data model,
  collaboration, runtime, browser behavior, migration, release gates, or package
  boundaries. Record the pre-mortem and expanded proof plan in this Plate Plan.
- [docs/editor-behavior/commands/README.md](docs/editor-behavior/commands/README.md)
  when resuming or reconsolidating the lane.
- [docs/research/systems/editor-behavior-architecture.md](docs/research/systems/editor-behavior-architecture.md)
  for cross-family architecture questions.
- [docs/analysis/editor-architecture-candidates.md](docs/analysis/editor-architecture-candidates.md)
  for framework-facing architecture/runtime questions.
- `../raw` when compiled research is missing, thin, stale, or contradictory.
- `build-web-apps:shadcn` when UI, editor chrome, shadcn components, registry
  components, overlays, command menus, inputs, forms, or styling are in scope.
- [vercel-react-best-practices](.agents/skills/vercel-react-best-practices/SKILL.md)
  when React/Next components, rendering, subscriptions, external stores,
  client/server boundaries, bundle size, data fetching, or runtime performance
  are in scope.
- [react-useeffect](.agents/skills/react-useeffect/SKILL.md) when effects,
  derived state, reset-on-prop, subscriptions, browser APIs, data fetching, or
  state synchronization are in scope.
- [performance-oracle](.agents/skills/performance-oracle/SKILL.md) when hot
  paths, algorithms, memory, network, query, bundle, browser/editor runtime, or
  scalability concerns are in scope.
- [tdd](.agents/skills/tdd/SKILL.md) when behavior changes, bug fixes, public
  interface changes, or regression classes need test-first acceptance criteria.

Use `research-wiki` when the compiled layer is stale, contradictory, or missing
coverage. For framework evidence, inspect local official clones under `..` or
normalized `../raw` before external docs.

If the review depends on current Plate behavior, cite live source files, docs,
examples, or tests. If it depends on external editor behavior, cite the compiled
research page or local source read used for the claim.

## Current-State Grounding

Current Plate source, docs, tests, generated artifacts, and editor-behavior law
win over old plans, stale research notes, generated handoffs, and memory.

Before any pass, score, protocol/parity row, authority-map decision, ledger row,
migration/adoption answer, docs/example answer, proof row, implementation
phase, final handoff, or user-facing explanation that relies on what currently
exists:

1. Re-read the live source, docs, examples, tests, generated artifact,
   editor-behavior file, browser contract, or external reference that owns the
   shape.
2. State the exact current owner: file, docs section, test, route, generated
   artifact, behavior-law row, research source, or explicit gap.
3. Quote or summarize the current shape only if it exists in that source.
4. Attach a file/line, docs section, test name, route, artifact path, behavior
   row, benchmark, or source URL.
5. If the current source already matches the proposed target, write
   `already done in live source` and move the decision to docs/tests/spec
   cleanup.
6. If no source-backed current shape exists, write `decision: ...`,
   `target shape: ...`, or `gap: ...` instead of inventing a current state.

Stale docs, old plans, audit history, and compiled research can explain why a
decision exists, but they cannot prove current Plate behavior when live evidence
is available.

For code/API/UI examples, grep the exact symbols first. For behavior-law claims,
read the relevant `docs/editor-behavior/**` files and any linked tests or
browser contracts first.

This applies to every related step, not only final before/after summaries. A
protocol row, parity row, objection, proof matrix row, migration answer,
implementation phase, or final chat answer can be wrong in the same way if it
uses a stale current state.

## Goal And Plan State

The active goal is the durable lane state. The plan is the durable evidence and
pass-state ledger. Do not create hook state for Plate Plan work.

Use the active plan for lightweight current-pass state:

```md
current_pass: current-state-read
current_pass_status: in_progress
next_pass: intent-boundary-and-decision-brief
next_action: finish current pass and update the plan
goal_status: active
```

Complete the goal only when all completion gates pass. Use `blocked` only when
no autonomous progress is possible because evidence, tooling, access, or a user
decision is missing.

Allowed `current_pass_status` values:

- `pending`
- `in_progress`
- `complete`
- `revise`
- `blocked`
- `skipped`

Single-pass completion is invalid by default:

- one activation may complete at most one scheduled review/spec pass
- a newly created or newly activated plan must stay `pending`
- only the closure pass may set `done`
- the closure pass is valid only after earlier pass-state rows are already
  recorded as complete in the active plan
- if the current activation creates, rewrites, or materially rescopes the plan,
  record the next pass and keep status `pending`
- ignore this only when the user explicitly asks for a single-pass review

Before completing the goal, prove in the plan:

- every scheduled pass row is `complete` or intentionally `skipped` with a
  concrete reason and evidence
- no pass row is `pending`, `in_progress`, `revise`, or `blocked` with a
  runnable next move
- `current_pass` is the closure/final-gates pass
- `current_pass_status` is `complete`
- `next_pass` is `none`
- `next_action` is `none`
- every completion threshold row below passes

If any assertion fails, keep the goal active and name the earliest runnable
`next_pass`.

## Confidence Score

Score every review pass from `0.00` to `1.00`.

Weights:

| Dimension | Weight |
| --- | ---: |
| Evidence and authority strength | 0.18 |
| Plate editor-behavior DX and product fit | 0.16 |
| Node model, affinity, and permanent-home coherence | 0.16 |
| Protocol, parity, and regression-proof testing | 0.20 |
| Research freshness and completeness | 0.15 |
| React/shadcn/effect implementation-review discipline | 0.10 |
| Roadmap and implementation-handoff clarity | 0.05 |

Score evidence rules:

- Every dimension score must cite concrete evidence: plan section, source file,
  docs section, protocol/parity row, test/browser contract, research page, or
  ledger row.
- A dimension without cited evidence cannot score above `0.80`.
- Research freshness cannot score above `0.85` without current citations for
  external systems or local repos the review relies on.
- Protocol/parity/regression cannot score above `0.80` without named
  replayable browser/unit/stress/protocol contracts.
- Permanent-home coherence cannot score above `0.85` if package ownership,
  performance cost, DX, and future consumer impact are not answered.
- Implementation-review discipline cannot score above `0.80` when an applicable
  shadcn, Vercel React, react-useeffect, performance-oracle, or tdd lens is
  missing.
- Implementation-review discipline cannot score above `0.85` when a lens is
  marked `applied` or `skipped` without findings, plan deltas, or a concrete
  skip reason.
- Any dimension affected by an unresolved intent, scope, non-goal, or decision
  boundary gap cannot score above `0.85`.
- A major decision with no viable-options comparison cannot score above `0.85`.
- A major decision with only one surviving option cannot score above `0.85`
  unless the invalidated alternatives are named and fairly rejected.

Completion threshold:

All rows are conjunctive. Passing score is necessary but never sufficient.

- total score `>= 0.92`
- no dimension below `0.85`
- no unplanned P0/P1 issue
- every dimension score has cited evidence
- no unresolved contradiction in the research layer
- no missing acceptance criteria for implementation
- no public behavior/API surface left in "maybe" language
- intent, outcome, in-scope, non-goals, and decision boundaries are explicit
- every major decision has principles, top drivers, viable options, rejected
  alternatives, consequences, and follow-ups
- high-risk deliberate mode is complete when triggered
- every major behavior/paradigm change has an accepted objection-ledger row
- extension/plugin/package/data-model changes have ecosystem answers when
  applicable
- every applicable shadcn, Vercel React, react-useeffect, performance-oracle,
  and tdd review is applied or explicitly skipped with a reason
- no objection-ledger row is `unresolved`, `revise`, or `drop` without a
  corresponding plan response
- pass schedule is complete
- pass-state ledger proves earlier passes completed before closure
- plan deltas from review are recorded
- final user-review handoff lists every accepted plan item/decision, with
  before/after shape when applicable

If any gate fails, status stays `pending`.

## Plan Shape

The plan must include:

1. Current verdict.
2. Intent/boundary record.
3. Decision brief.
4. Confidence scorecard with evidence references.
5. Source-backed behavior north star.
6. Request classification and feature family.
7. Current law/readiness state.
8. Research freshness decision.
9. Node model and affinity target.
10. Permanent-home target.
11. Standards/spec/protocol/parity/audit/roadmap change map.
12. Applicable implementation-skill review matrix: shadcn, Vercel React,
    react-useeffect, performance-oracle, and tdd.
13. Browser stress / parity / regression strategy.
14. High-risk deliberate-mode pre-mortem and proof plan when triggered.
15. Hard cuts and rejected alternatives.
16. Objection ledger with ecosystem answers when triggered.
17. Pass schedule and pass-state ledger.
18. Plan deltas from review.
19. Open questions and what would change the decision.
20. Implementation phases with owners.
21. Fast driver gates.
22. Final user-review handoff outline.
23. Final completion gates.

## Pass Schedule

Run the review as passes, not one giant essay:

1. Current-state read and initial score.
2. Intent/boundary and decision-brief pass; write the boundary record directly
   when it is not already explicit.
3. Research and live-source refresh.
4. Authority, node-model, affinity, permanent-home, protocol, parity, roadmap,
   shadcn, React performance, useEffect, performance-oracle, tdd, and
   regression pressure passes.
5. Plate maintainer objection ledger with steelman pressure for major decisions.
6. High-risk deliberate-mode pass when triggered.
7. Ecosystem maintainer pass when triggered.
8. Revision pass that answers objections and updates the plan/spec stack.
9. Closure score and final gates.

The closure score and final gates are their own pass. Do not fold closure into
the previous pass. The closure pass may start only when every earlier
pass-state row is already `complete` or intentionally `skipped` with evidence.

After each pass, update the active plan with pass status, evidence, changes,
and next owner. Keep the active goal open while any pass or revision remains
runnable.

Pass-state ledger rows must include:

- pass name
- status: `pending`, `in_progress`, or `complete`
- evidence added
- plan delta
- editor-behavior output delta
- open issues
- next owner

Do not mark multiple major passes complete in one activation. Finish the current
pass, refresh the active continuation prompt, keep status `pending`, and let the
next activation run the next pass.

## Editor-Behavior Outputs

This workflow answers four questions:

1. What is the authority?
2. What is the readable law?
3. What are the exhaustive scenarios?
4. What is the current gate status?

That maps to:

- authority -> [markdown-standards.md](docs/editor-behavior/markdown-standards.md)
- readable law -> [markdown-editing-spec.md](docs/editor-behavior/markdown-editing-spec.md)
- exhaustive scenarios -> [editor-protocol-matrix.md](docs/editor-behavior/editor-protocol-matrix.md)
- gate status -> [markdown-parity-matrix.md](docs/editor-behavior/markdown-parity-matrix.md)
- evidence history -> [markdown-editing-reference-audit.md](docs/editor-behavior/markdown-editing-reference-audit.md)
- implementation queue -> [master-roadmap.md](docs/editor-behavior/master-roadmap.md)

For each output file, either patch it or state why it stayed unchanged. Do not
leave a layer implicit.

## Intake Classification

Classify the request before editing:

1. Update to existing current feature behavior.
2. New interaction class for an existing current feature.
3. New current feature family or newly formalized current surface.
4. Deferred or future feature.
5. New authority / winner shift.
6. Architecture-only spec question.
7. Regression-proofing / parity gate question.

Classify the feature family:

- markdown-native syntax
- markdown mode architecture and note-linked navigation
- block-editor-native elements
- tables and linear document editing
- collaboration / editor-only
- styling / layout / editor chrome
- cross-surface interaction

Classify the evidence state:

- evidence already sufficient
- research update needed
- architecture lane change
- pure law/protocol update
- parity/proof update

## Intent Boundary Gate

Before treating a plan as ready, record:

- intent: why the user wants this change
- desired outcome: what state should exist after implementation
- in-scope behavior
- non-goals
- decision boundaries: what the plan may decide without asking the user again
- unresolved user-decision points

Gather repo facts before asking the user about internals. If one user answer is
needed, ask exactly one high-leverage boundary question, not a questionnaire.

Pressure-test weak answers with one of:

1. concrete example, counterexample, or evidence signal
2. hidden assumption or dependency
3. explicit tradeoff, rejected boundary, or deferred scope
4. root-cause reframing when the request describes only symptoms

Do not score ready while non-goals or decision boundaries are vague.

## Decision Brief

For every major behavior, authority, package-boundary, API, protocol, or proof
decision, record:

- principles: three to five rules the decision must satisfy
- top drivers: the three forces that most affect the decision
- viable options: at least two, with bounded pros and cons
- chosen option
- rejected alternatives
- consequences
- follow-ups

If only one option is viable, say which alternatives were considered and why
they are invalid. "No alternative" is not a reason; it is usually a missed pass.

## Research Decision

Use the research layer before inventing new law.

Use `research-wiki` for choosing and running the right research mode when:

- the topic already exists in `docs/research` but needs refresh
- compiled synthesis is contradictory or thin
- raw evidence is missing or stale
- the authority question spans multiple likely corpora
- the surface is authority-sensitive and silence would be dangerous

Do not skip the research layer and jump from a raw source into law unless the
request is tiny and the evidence is already obvious.

Do not call research "full" if one likely corpus stayed silent. Silence is a
gap, not agreement.

## Evidence Ladder

Use:

1. explicit reference docs or executable tests
2. compatible but indirect evidence
3. honest gap

When recording evidence, use:

- `agree`
- `partial`
- `gap`
- `tension`
- `diverge`

Never mark behavior `locked` because it feels standard.

Live source/docs/tests/generated artifacts and behavior-law files outrank
compiled research and previous plans when describing the current state. If they
disagree, record `stale research`, `stale plan`, or `stale audit history` and
update the active plan from live evidence.

## Node Model First

Before writing UX law, lock:

1. node model
2. affinity class when relevant

Node model classes:

- `block non-void`
- `block void atom`
- `inline non-void span`
- `inline void atom`
- `leaf mark`
- `text token`
- `overlay / no node`

Affinity classes:

- `directional`
- `hard`
- `outward`
- `none / n-a`

Do not spec hover, click, backlink, toolbar, or popover behavior until the model
is explicit.

## Permanent-Home Test

For any new shared contract or cross-surface rule, answer:

1. What is the best permanent home if designed cleanly today?
2. Which home minimizes repeated feature-local reimplementation?
3. Which home keeps package ownership coherent?
4. Which home gives the best performance characteristics?
5. Which home gives the best DX and API discoverability?
6. Which future consumers would reuse it?

Candidate homes:

- `@platejs/core`
- existing shared package
- new shared package
- feature package
- app/render layer only
- docs/test contract only

If the answer differs from current file placement, the spec should say so.

## Required Edit Order

Use this order unless the task is small enough that a subset is obviously
enough. If a file stays unchanged, record why.

### 1. Standards

Patch [markdown-standards.md](docs/editor-behavior/markdown-standards.md) when:

- the winner map changes
- a new authority lane appears
- a family split is needed
- a stronger external reference replaces an older one
- routing guidance changes

### 2. Readable Law

Patch [markdown-editing-spec.md](docs/editor-behavior/markdown-editing-spec.md)
to define:

- family-level behavior
- node model
- affinity
- ownership rules
- locked notes / exceptions
- current vs deferred status

If behavior includes editor chrome or navigation UI, define it in a way that is
compatible with shadcn composition: popovers, commands, menus, triggers,
truncation, keyboard composition, semantic styling, and no one-off overlay
markup when a standard pattern exists.

If behavior includes React rendering, subscriptions, overlays, server/client
boundaries, data fetching, or editor runtime projections, define the performance
shape explicitly: what subscribes, what stays static, what work is deferred, and
which Vercel React rule family applies.

If behavior includes effects, derived state, reset-on-prop behavior,
subscriptions, browser APIs, external stores, or data synchronization, define why
an effect is needed. Prefer render-time calculation, event handlers, keyed
resets, `useMemo`, or `useSyncExternalStore` when they express the behavior.

### 3. Protocol Rows

Patch [editor-protocol-matrix.md](docs/editor-behavior/editor-protocol-matrix.md)
to enumerate:

- concrete scenarios
- authority per row
- spec IDs
- status

If a surface has different winners by scenario, split the rows. Do not keep one
coarse row that lies.

### 4. Parity Gate

Patch [markdown-parity-matrix.md](docs/editor-behavior/markdown-parity-matrix.md)
when:

- an existing current feature family changed
- the family authority map changed
- gate status changed
- node model / affinity summary changed
- browser/protocol proof changed

Do not inflate the parity matrix for speculative future product ideas that are
not current Plate features.

### 5. Roadmap

Patch [master-roadmap.md](docs/editor-behavior/master-roadmap.md) when:

- a new implementation lane appears
- deferred implementation work should enter the queue
- order of real remaining implementation lanes changes
- a lane is narrowed, closed, re-cut, or split

Do not strand implementation debt only in parity wording or a plan doc.

### 6. Audit

Patch [markdown-editing-reference-audit.md](docs/editor-behavior/markdown-editing-reference-audit.md)
only when:

- a new external reference disagreement matters
- the evidence history needs a new entrypoint
- a winner shift needs explicit audit history

Do not treat the audit as current law.

## Current Feature Vs Deferred Feature

For current feature/current surface, update all affected layers:

- standards
- readable law
- protocol rows
- parity when the gate changed
- roadmap when implementation work remains
- audit when evidence history changed

For deferred or future surfaces, usually update:

- standards if a new lane is needed
- readable law if the contract must exist now
- protocol rows as `deferred` or `specified`

Do not pretend deferred behavior is release-gated current behavior.

## Applicable Implementation Reviews

Before scoring above threshold, decide whether each review lens applies. Record
the decision in the active plan even when skipped.

Use this matrix:

| Lens | Applies when | Must answer |
| --- | --- | --- |
| `build-web-apps:shadcn` | UI/editor chrome, components, registry components, menus, popovers, command palettes, inputs, forms, overlays, styling, or component composition are in scope | Are existing components used first? Are variants, semantic tokens, `gap-*`, `size-*`, `truncate`, `cn()`, accessible titles, grouped menu/select items, full Card composition, Button loading, and icon `data-icon` rules respected? |
| `vercel-react-best-practices` | React/Next components, rendering, external-store subscriptions, data fetching, server/client boundaries, bundle size, or runtime performance are in scope | Are waterfalls avoided, bundles split sanely, server/client serialization minimized, global listeners deduped, subscriptions derived and narrow, expensive renders deferred, transient values kept in refs, and inline components avoided? |
| `react-useeffect` | `useEffect`, `useState` for derived values, reset-on-prop, state synchronization, subscriptions, browser APIs, external systems, data fetching, or parent notifications are in scope | Is the effect actually synchronizing with an external system? Can the behavior be render calculation, `useMemo`, keyed reset, event handler, framework fetch, or `useSyncExternalStore` instead? |
| `performance-oracle` | Hot paths, algorithms, large collections, memory lifetime, network/database I/O, bundle cost, editor runtime loops, browser event paths, or scalability are in scope | Is complexity bounded? Are allocations, subscriptions, listeners, network calls, and cache lifetimes controlled? What happens at 10x, 100x, and 1000x scale? |
| `tdd` | Behavior additions, bug fixes, public interface changes, regression classes, or executable acceptance criteria are in scope | Is there a red-green-refactor slice through a public interface? Does the test verify behavior rather than implementation details? |

For each applicable lens, record:

- applicability: `applied` or `skipped`
- reason
- findings
- plan delta or explicit no-change defense
- proof pointer: plan section, source file, rule family, protocol row, or test
  family

Do not turn these lenses into generic busywork. If the plan is pure law with no
UI, React, or effect surface, skip them with one sentence and keep moving.

## High-Risk Deliberate Mode

Trigger this mode when a proposal changes:

- public API
- package boundary
- data model
- extension/plugin behavior
- collaboration or operation semantics
- normalization
- selection, focus, IME, or browser-runtime behavior
- release gate or generated regression contract

When triggered, add to the active plan:

- pre-mortem: three realistic failure scenarios
- expanded proof plan: unit, browser, parity, stress, migration, and docs/example
  proof as applicable
- blast-radius note: packages, examples, docs, tests, and downstream consumers
- rollback or hard-cut answer: why the plan is still worth doing

High-risk mode is not a separate workflow. It is one stricter pass inside this
skill.

## Objection Ledger

Simulate a skeptical Plate maintainer and serious downstream Plate user.
The goal is to prevent "they changed things for no reason."

For every major behavior, authority, API, package-boundary, protocol, or parity
change, record:

- Change: exact behavior/API/spec/test contract being changed.
- Who feels pain: Plate user, plugin author, app author, docs maintainer,
  test maintainer, package owner, design-system owner, or release owner.
- Likely objection: strongest fair complaint in user language.
- Steelman antithesis: the best argument for not making the change.
- Tradeoff tension: what the chosen option makes worse or more expensive.
- Why this is not change for change's sake: concrete payoff.
- Evidence: repo fact, research fact, protocol row, parity row, browser
  regression class, or reference limitation.
- Rejected alternative: closest compatible option and why it is weaker.
- Adoption answer: how a user or maintainer moves from old shape to new shape.
- Docs/example answer: what public explanation or example proves the change.
- Regression proof: unit, browser, protocol, parity, stress, or manual proof row.
- Ecosystem answers, when triggered.
- Verdict: `keep`, `revise`, `drop`, or `unresolved`.

Ledger rows are mandatory for changes like:

- new authority lane or winner shift
- family split
- node model or affinity change
- permanent-home decision
- core vs package vs app/render ownership change
- shadcn/editor-chrome behavior contract
- React runtime/rendering/subscription behavior contract
- effect, derived-state, or external-synchronization contract
- protocol/parity gate change
- roadmap order change
- hard cut of old docs/API behavior
- generated browser or stress-test gate

Rules:

- No major behavior/paradigm change may score above `0.85` in DX, authority, or
  parity unless it has a ledger row with a convincing answer.
- A ledger row is accepted only when its verdict is `keep` and every required
  field is concrete: evidence, steelman antithesis, tradeoff tension, rejected
  alternative, adoption answer, docs/example answer, regression proof, and
  ecosystem answers when triggered.
- A row is not accepted if a required field is missing, says `TBD`, says only
  "cleaner", or lacks proof that a real user problem is solved.
- If the best answer is only "cleaner", the verdict is `revise` or `drop`.
- `unresolved`, `revise`, or `drop` rows must feed back into the plan before
  completion can be `done`.
- Reuse prior ledger rows when rerunning this skill, but revalidate them against
  the latest plan.

## Ecosystem Maintainer Pass

Do not create separate full ledgers by default. Trigger this pass only when the
proposal changes extension, plugin, package, rendering, collaboration,
operation, identity, normalization, snapshot, or data-model behavior.

For each triggered ledger row, add short answers:

- Plugin maintainer: can packages expose this without wrapping every core call
  or creating a compatibility junk drawer?
- App author: can app code customize or opt out without bespoke wiring?
- Docs/test maintainer: can docs, examples, protocol rows, and proof gates stay
  coherent?
- Collab/data maintainer, when relevant: do operations, identity, snapshots,
  normalization, remote apply, and conflict behavior stay deterministic?

For core API/data-model changes, also name:

- exact affected extension points
- package/plugin migration surface
- data/collab contract affected
- proof required before closure

The pass catches ecosystem breakage. It does not veto every cleanup.

## Plan Deltas From Review

Every review pass must either change the plan or explicitly defend no change.

Record:

- added decisions
- revised decisions
- dropped decisions
- strengthened acceptance criteria
- new tests/proof rows
- editor-behavior output file deltas
- unresolved items moved to the next pass
- no-change decisions with evidence

If pressure passes produce no plan delta and no explicit no-change defense, the
review is a rubber stamp and completion stays `pending`.

## Pressure Passes

Before raising the score above threshold, run these passes and record the result
in the plan:

- Authority pass: prove the winner map and family split are justified.
- Intent/boundary pass: prove intent, outcome, scope, non-goals, and decision
  boundaries are explicit.
- Decision-brief pass: prove principles, drivers, options, rejected
  alternatives, consequences, and follow-ups are recorded.
- Node-model pass: prove model and affinity are locked before UX law.
- Permanent-home pass: prove ownership belongs where the plan says it belongs.
- DX pass: prove the shape is discoverable for Plate users and future agents.
- Unopinionated-core pass: prove core does not absorb product-only opinion.
- Regression pass: prove behavior is caught by protocol/parity/browser/stress
  contracts, not example-by-example patching.
- Research pass: prove compiled research was used as evidence, not decoration.
- shadcn/UI pass: when applicable, prove editor chrome follows composable
  shadcn patterns and record the applied/skipped result.
- Vercel React pass: when applicable, prove React runtime/performance choices
  follow the relevant Vercel rule families and record the applied/skipped result.
- useEffect pass: when applicable, prove effects are external-system
  synchronization, not derived-state or event-handler work in disguise.
- Performance-oracle pass: when applicable, prove hot-path, complexity, memory,
  network, bundle, and scalability claims are bounded or intentionally deferred.
- TDD pass: when applicable, prove behavior changes and regression classes have
  public-interface red-green-refactor acceptance criteria.
- Simplicity pass: remove overbuilt props, aliases, shims, and speculative API
  layers.
- Plate maintainer pass: challenge every major behavior/paradigm change as if
  reviewing a Plate PR; record objections and answers in the ledger.
- Steelman pass: record the best antithesis and real tradeoff tension for each
  major decision.
- High-risk deliberate pass: when triggered, add the pre-mortem and expanded
  proof plan before closure.
- Ecosystem pass: only when triggered, add plugin/app/docs/test/data answers to
  the same ledger row.

## User Review And Execution Mode

When the score is below threshold, any required pass remains open, or any
completion gate has a runnable next move:

1. Update the plan with the current score, evidence, rejected tactics, and next
   owner.
2. Keep the active goal open.
3. Continue the next review/refinement slice.

When final gates pass, complete the planning goal and stop for user review.
Implementation starts only after a later explicit execution request that invokes
Plate Plan again against the accepted plan. That execution invocation must use a
new execution-shaped goal, read the accepted plan, run the next implementation
owner, record verification, and keep the goal active while any accepted owner
remains runnable.

## Done Handoff

When setting completion to `done`, the final chat response must include a
concise but exhaustive bullet list of every accepted plan item and decision so
the user can review without opening the full plan.

Group bullets by surface when useful:

- authority / winner map
- intent / decision brief
- node model / affinity
- permanent home / package ownership
- editor-behavior outputs
- protocol / parity / roadmap / audit
- UI/editor chrome and applicable shadcn review
- React runtime/performance and applicable Vercel React review
- effects/external synchronization and applicable react-useeffect review
- hot-path/scalability and applicable performance-oracle review
- behavior/regression proof and applicable tdd review
- high-risk deliberate-mode pre-mortem when triggered
- regression proof
- hard cuts and rejected alternatives
- implementation phases and gates

Each bullet should include:

- decision name or surface
- before -> after shape when the plan changes an existing shape, with a source
  pointer for the before
- status: `add`, `keep`, `cut`, `rename`, `revise`, or `gate`
- proof pointer when short enough: evidence row, ledger row, test/proof family,
  spec section, or plan section

Current-state / before-after rules:

- Any claim about the current implementation, behavior law, docs state, example,
  protocol row, parity row, or generated artifact must have a live evidence
  pointer or be marked `gap`.
- `before` must be copied from live source, docs, examples, tests, generated
  artifacts, behavior-law rows, or authoritative reference material.
- `after` must be an accepted target shape or `already done`.
- If a previous plan, audit, or compiled research claims an old shape but live
  evidence does not, do not use it in any step; record `stale claim`.
- If a decis

…(truncated)