Technical Documentation: udecode/plate

ℹ️ Provenance: Multi-Tier Ingestion · CodeWiki Reference

Overview (`README.md`) Copy Section

Plate

Templates Copy Chapter

You can choose one of the following templates to get started:

Documentation Copy Chapter

You can learn more about Plate by checking out our documentation.

Contributing Copy Chapter

To get started, check out our contributing guide.

Contributors Copy Section

We'd love for you to join us! Whether it's through giving us a 🌟 star, making a 📥 pull request, or sharing your plugins, your help is always appreciated.

Need more help? Join us on Discord. We're always here to guide you.

中文文档 Copy Chapter

您可以通过查看我们的中文文档了解更多关于Plate的信息。如果您需要中文支持，欢迎加入我们的Discord中文频道，我们的社区成员将很乐意用中文为您解答问题。

对于贡献者，我们也提供了中文贡献指南，帮助您参与到Plate的开发中。

Overview (`.changeset/README.md`) Copy Section

Changesets

Hello and welcome! This folder has been automatically generated by @changesets/cli, a build tool that works
with multi-package repos, or single-package repos to help you version and publish your code. You can
find the full documentation for it in our repository

We have a quick list of common questions to get you started engaging with this project in
our documentation.

Overview (`apps/www/README.md`) Copy Section

Documentation

This is the documentation for the Plate project.

Usage Copy Chapter

Anytime you make a change in the registry folder, run:

pnpm build:registry

License Copy Chapter

MIT

Overview (`benchmarks/editor/README.md`) Copy Section

Editor Evidence

This directory is an Evidence Kit lab for editor framework benchmark research.

It replaces the old standalone Next/Vite benchmark app. The default owner is
now evidence artifacts, not browser app scaffolding.

Commands Copy Chapter

npm run evidence:inspect
npm run research:list
npm run research:editor-frameworks:fetch
npm run test:evidence
npm run fuzz
npm run bench:evidence
npm run bench:rich-text:check
npm run bench:startup:check
npm run bench:package:gates
npm run bench:scope
npm run evidence:health
npm run evidence:refresh
npm run docs:perf
npm run docs:perf:search -- editor benchmark
npm run evidence:full

Source Map Copy Chapter

Primary target list:

• Slate v2
• Slate

Primary source config:

• research/editor-frameworks-sources.json

Primary benchmark registry:

• research/benchmark-registry.json

Active Benchmark Matrix Copy Chapter

benchmarks/results/rich-text-editors-latest.json is the broad benchmark
matrix. It imports active artifacts from research/benchmark-registry.json.
Old one-off benchmark JSON files do not count unless they are registered there.
The active scope is Slate v2 vs Slate only.

Measured Slate v2 families:

• React huge-document legacy compare
• React rerender breadth
• React huge-document overlays
• React huge-document browser trace
• React active typing breakdown
• Core normalization, query/ref observation, node transforms, text/selection,
  editor store, and refs/projection
• Core huge-document, normalization, observation, and history compares against
  Slate
• Clipboard large payload, collab readiness, and issue #6038 transaction
  execution rows

Local source targets:

• Slate v2
• Slate

Slate baseline rule:

• Use Slate chunk-on as the baseline. Do not emit chunk-off rows in active
  comparison output.

The first direct runtime comparison still lives in:

• benchmarks/results/slate-v2-legacy-latest.json

The comprehensive result lives in:

• benchmarks/results/rich-text-editors-latest.json

The health and next-action report lives in:

• benchmarks/results/benchmark-health-latest.json

Rule Copy Chapter

Do not restore the old app/template lab by default. Do not promote random
historical tmp JSON. Add a registry entry, target-owned adapter, fuzzer, corpus
case, benchmark row, or source-pass note when a comparison needs new evidence.

Overview (`benchmarks/targets/README.md`) Copy Section

Benchmark Targets

This directory is the migration spine for Slate benchmark work.

The target registry answers one question: what benchmark decision are we
measuring, and how does an agent run or optimize it?

Ownership Copy Chapter

• Benchmark implementation lives beside the runtime/package code it measures.
• benchmarks/targets/slate-v2.json names active benchmark targets, cohorts,
  metrics, commands, correctness checks, artifacts, and source links.
• Autoresearch sessions optimize one target id at a time.
• Evidence Kit is a legacy import/report archive until generated reports move
  to this registry.

Commands Copy Chapter

pnpm bench:targets:list
pnpm bench:targets:check
pnpm bench:targets:report
pnpm bench:targets:report:check
pnpm bench:targets:dry-run -- react-active-typing-breakdown
pnpm bench:targets:run -- react-active-typing-breakdown
node tooling/scripts/bench-targets.mjs autoresearch-init react-active-typing-breakdown

bench:targets:dry-run is read-only. It checks the registry and prints the
Autoresearch setup plan for the target. Use autoresearch-init only when you
want to create or replace the real .tmp/slate-v2/autoresearch.* session files.
For operator workflows, invoke the slate-ar* skills instead of package
scripts.

Use pnpm bench:targets:import-evidence-kit only while migrating active rows
from benchmarks/editor/research/benchmark-registry.json. After the cutover,
edit target definitions here directly.

Target Contract Copy Chapter

Each target has:

• id: stable command-facing id
• question: decision the benchmark answers
• owner: runtime/package owner
• family and kind: grouping for reports
• cwd and command: repo-relative run location and command
• metrics: primary metric, direction, unit, and whether output prints
  METRIC name=value
• correctness: command that prevents speed wins from breaking editor behavior
• artifacts: result files produced by the target
• docs: supporting evidence links
• migration: temporary provenance while Evidence Kit is being retired

Benchmark output should move toward native METRIC and ARTIFACT lines. Until
then, Autoresearch can wrap timing with metrics.printsMetric: false.

Generated Outputs Copy Chapter

pnpm bench:targets:report writes:

• benchmarks/targets/history/slate-v2-latest.json
• benchmarks/targets/reports/slate-v2.md

These are the target-registry replacement for Evidence Kit's active
health/report surface. They summarize target status from registered artifacts.
They do not run expensive benchmarks.

pnpm bench:targets:dry-run -- <target-id> checks the registry, builds the
report model in memory, and asks Autoresearch for a setup plan for that target.
Use it before starting a real optimization loop.

Overview (`docs/editor-behavior/README.md`) Copy Section

Editor Behavior Docs

This directory is the source of truth for editor-behavior standards and
coverage.

Use it to answer three different questions:

1. What is the decision model?
2. What behavior do we want?
3. What is actually covered right now?

Start Here Copy Chapter

• Read markdown-standards.md first.
  It defines the authority methodology:
  • syntax specs first
  • choose references per concrete surface, not by broad category default
  • use candidate pools such as Typora, Obsidian, Google Docs, Notion,
    GitHub, and Milkdown as routing hints, not governing winners
• If you want to resume or operate this lane without re-reading everything,
  start with
  commands/README.md.

File Guide Copy Chapter

• markdown-parity-matrix.md
  The family-level coverage gate.
  Use this to see:

  • which existing feature families are covered
  • what evidence exists
  • what is deferred
  • what still blocks a release

• master-roadmap.md
  The canonical remaining implementation roadmap.
  Use this to see:

  • what is already closed
  • what still remains to implement
  • lane order and next-batch sequencing
  • which supporting plans own each remaining lane

• editor-protocol-matrix.md
  The exhaustive scenario matrix.
  Use this to see:

  • the protocol schema for scenario-complete behavior coverage
  • row-level scenarios, authorities, and evidence mapping
  • scenario dimensions for full behavior coverage
  • which rows are tested, specified, partial, or deferred
  • which interaction classes are still deferred into the integration red suite

• markdown-editing-spec.md
  The normative behavior spec.
  Use this to see:

  • invariants
  • ownership rules
  • canonical behavior examples
  • locked policy calls

• markdown-editing-reference-audit.md
  Reference evidence.
  Use this to see:

  • what the first Typora / Milkdown audit says
  • where that first audit still matters
  • where newer Obsidian research adds stronger product pressure
  • where Plate had to choose

• editor-behavior-architecture.md
  Long-horizon architecture.
  Use this when the question is:

  • should behavior stay plugin-scattered?
  • what would a profile-driven model look like?
  • how would Plate support Typora / Obsidian / Notion / Docs-style profiles cleanly?

Supporting Dirs Copy Chapter

• execution notes live under docs/plans
  The main historical editor-behavior execution notes are:
  2026-04-02-editor-behavior-major-execution.md
  and
  2026-04-03-editor-protocol-matrix-completion.md.
  Use them for batch history, not as the current gate source.
  Current gate truth belongs to
  markdown-parity-matrix.md.
  Current implementation-roadmap truth belongs to
  master-roadmap.md.
  This cleanup pass is tracked in
  2026-04-03-editor-behavior-doc-structure.md

• operator commands live under
  commands
  Use this as the resume surface for reconsolidation, evidence refresh,
  re-interview, re-planning, and batch launch.

• docs/research
  Compiled external-reference research.
  Use this for Typora-, Obsidian-, and Milkdown-derived source summaries,
  concepts, decisions, and system maps.

• ../raw
  Private raw evidence layer.
  Use this for full third-party corpora when deeper verification is needed.

• docs/solutions
  Reusable learnings, including the editor-behavior methodology docs that were
  moved out of this folder.

Reading Order Copy Chapter

If you want the big picture Copy Section

1. markdown-standards.md
2. editor-behavior-architecture.md
3. markdown-parity-matrix.md
4. master-roadmap.md

If you want the current release gate Copy Section

1. markdown-parity-matrix.md
2. commands/README.md
3. 2026-04-02-editor-behavior-major-execution.md only when you need the historical execution trail

If you want to resume or maintain the lane Copy Section

1. commands/README.md
2. master-roadmap.md
3. markdown-parity-matrix.md
4. 2026-04-02-editor-behavior-major-execution.md when you need batch history

If you want concrete behavior rules Copy Section

1. markdown-editing-spec.md
2. markdown-editing-reference-audit.md
3. docs/research when you need the
   compiled external-reference layer behind the audit

If you want exhaustive protocol coverage Copy Section

1. editor-protocol-matrix.md
2. markdown-editing-spec.md
3. markdown-parity-matrix.md

Practical Rule Copy Chapter

• Use the spec to define behavior.
• Use the protocol matrix to enumerate exhaustive scenarios.
• Use the parity matrix to decide whether a family is covered enough.
• Use the audit when a rule needs external grounding.
• Use the architecture doc only when the question is structural, not behavioral.
• If two docs appear to say the same thing, the spec wins for law, the protocol
  matrix wins for exhaustive cases, and the parity matrix wins for ship gate.

Overview (`docs/performance/README.md`) Copy Section

Performance Docs

This directory is the human-facing source of truth for Plate editor
performance work.

Read Order Copy Chapter

1. editor-performance-master-plan.md
   • the main program document
   • current state, key wins, remaining red lanes, and sequencing
2. plate-vs-slate-benchmarks.md
   • benchmark narrative and forensic history
   • use this when you need to understand why a cut mattered
3. editor-performance-next-phase-consensus.md
   • planning artifact for the earlier “what next” decision
   • useful for rationale, not for the latest numbers
4. performance-benchmark-spec.md
   • benchmark contract for the public Performance guide
   • defines scope, workloads, and claim boundaries
5. 2026-04-04-standalone-benchmark-gap-analysis.md
   • why the standalone rich-markdown lab exposed a Plate mount gap
   • current diagnosis and next optimization targets
6. 2026-04-03-affinity-redesign-plan.md
   • plan for the hard-affinity code-mark redesign
7. 2026-04-03-remaining-basic-nodes-benchmark.md
   • plan for the remaining @platejs/basic-nodes census extension

Artifact Policy Copy Chapter

• Durable markdown lives here.
• Raw benchmark JSON lives in .tmp/.
• Older docs may still mention docs/plans/*.json from before the raw
  artifact move. When that happens, prefer the matching file in .tmp/.
• Internal one-off planning/proof notes belong under docs/plans/, not
  here, unless they are directly useful to understanding the performance story.

Release Snapshot Copy Chapter

As of 2026-04-03:

• plain core is good enough versus Slate
• insert-text perf is good enough
• nodeId is no longer the cliff
• the dedicated nodeId paste/import lane now exists, and it shows:
  • raw import is basically cheap
  • duplicate-id paste is the only remaining meaningful withNodeId hotspot
• code-affinity redesign landed and materially improved the worst core-plugin
  lane
• newly benchmarked remaining basic-nodes plugins split cleanly:
  • green enough: KbdPlugin, SubscriptPlugin, SuperscriptPlugin
  • still red: HighlightPlugin, StrikethroughPlugin

What Is Left After Release Copy Chapter

If we ship now, the meaningful remaining performance work is:

1. HighlightPlugin
   • currently still well behind Slate on the activated lane
2. StrikethroughPlugin
   • same story; cheap mark path still too expensive
3. Table selection
   • still a separate real hotspot, not solved by core editor work
4. Performance-doc cleanup
   • some historical JSON artifact links still need cleanup/consolidation

What Is Not Worth Chasing Right Now Copy Chapter

• more cheap-mark surgery on bold/italic/underline
• insert-text perf
• more init-time nodeId surgery without a new duplicate-paste result
• chunking rhetoric without a new workload
• more code-affinity tuning unless behavior bugs appear

Overview (`docs/research/README.md`) Copy Section

Agent Research Layer

This is the compiled research layer for Plate.

It exists to give future agents a stable, low-token, persistent reference
surface that sits between raw evidence and day-to-day task execution.

This is not a human PKM system. It is not an Obsidian workflow. It is not a
generic RAG bucket.

The raw evidence layer lives outside this repo in ../raw relative to the
Plate repo root. That private repo is assumed to be cloned locally when agents
need to verify or deepen compiled summaries.

Core idea Copy Chapter

Most agent work still behaves like raw RAG:

• read the repo
• search scattered docs
• search issues, plans, and learnings
• stitch the answer together again from scratch

That works, but it wastes tokens and keeps rediscovering the same decisions,
the same caveats, and the same contradictions.

The better model is a compiled research layer:

• raw evidence stays in ../raw
• compiled summaries, decisions, concepts, and system maps live here
• agents read this layer first
• agents drop to ../raw only when they need verification, conflict
  resolution, or deeper evidence

The valuable artifact is not one answer in one chat. It is the maintained
markdown layer that makes the next agent faster and less likely to repeat old
mistakes.

Layers Copy Chapter

1. Raw evidence Copy Section

Private, source-heavy, and often copyright-sensitive material.

Expected location:

• ../raw

Examples:

• captured third-party editor docs
• screenshots
• extracted page text
• local corpora
• transcripts
• external-source inventories

This layer is the evidence base. It is not the default answer surface.

Raw acquisition policy Copy Section

Prefer the strongest stable acquisition method:

1. official git repo clone
2. official export or local cache
3. page capture or scrape only when no better source exists

If an official git repo exists, use that as the canonical raw source instead of
inventing a scrape.

Examples:

• Milkdown: official repo cloned under ../raw/milkdown/repo
• Obsidian: official help and developer-docs repos cloned under ../raw/obsidian
• Typora: local cached corpus copied into ../raw/typora

Raw snapshot metadata Copy Section

Every raw source family should record enough metadata that future agents can
trust what they are reading.

Record at least:

• canonical source URL or repo URL
• local raw path
• snapshot date
• current revision when available:
  • git commit hash for repos
  • fetched timestamp for caches or exports
• lightweight counts when useful

Raw sync policy Copy Section

Do not refresh every raw source on every task. That is wasteful and noisy.

Refresh raw sources when:

• the area is active in the current task
• drift matters to the decision
• the source has likely changed since the last meaningful ingest

When a raw source is refreshed:

• update its raw README or metadata
• append ../raw/log.md
• refresh affected compiled pages if the new evidence changes them

2. Compiled research Copy Section

This directory, docs/research, is the agent-facing compiled layer.

It contains:

• source summaries
• decisions
• concepts
• systems
• entities
• open questions
• index and log files

This layer should be:

• concise
• metadata-first
• link-heavy
• easy to grep
• safe to keep in the public repo

3. Agent contract Copy Section

Agents should treat this directory as the default read layer for repo
knowledge.

The rule is simple:

1. read docs/research/index.md
2. read the relevant compiled pages
3. only then drop to ../raw or broader repo search

Design rules Copy Chapter

Stable paths beat cute structure Copy Section

Keep the layout boring and guessable.

Current top-level structure:

• index.md
• log.md
• schema.md
• commands/
• sources/
• decisions/
• concepts/
• systems/
• entities/
• open-questions/

Do not split the research layer into parallel goal-specific silos like:

• editor-behavior/
• architecture/
• plate-v2/
• slate-v2/

That looks tidy for a week and then turns into duplicate pages and drifting
taxonomy.

Use one research layer, many domains, one page-type system.

commands/ is the one intentional support surface that is not a knowledge-type
bucket. It exists for repeatable operational workflows, not for domain pages.

One concept per file Copy Section

Do not build giant mixed essays.

Good:

• one file for one source summary
• one file for one decision
• one file for one concept
• one file for one system map
• one file for one entity

Bad:

• giant pages that mix multiple concerns and force future agents to dig through
  noise

Organize by knowledge type, not by temporary project goal Copy Section

This research layer should be DRY at the page-type level.

Use:

• sources/ for compiled source summaries
• entities/ for concrete named things
• concepts/ for reusable abstractions and vocabulary
• systems/ for larger maps and architecture surfaces
• decisions/ for explicit conclusions
• open-questions/ for unresolved ambiguity

Do not duplicate the same thing across multiple goal folders.

Examples:

• one page for Typora
• one page for Slate
• one page for directional-affinity
• one page for inline-void-atom
• one page for editor-architecture-landscape
• one page for footnote-refs-are-inline-void-atoms

That page can serve many goals:

• editor-behavior work
• Plate v2 architecture work
• Slate v2 comparison work
• plugin-system analysis

The page type stays stable even when the project focus changes.

Claims point outward Copy Section

This research layer is a normalized interpretation layer, not a vibe layer.

Durable claims should point to evidence in:

• ../raw
• repo files
• source-of-truth docs
• plans
• learnings

Compiled pages stay derived Copy Section

Do not copy raw third-party docs into this repo.

This research layer should contain:

• paraphrased summaries
• normalized decisions
• compact cross-source synthesis
• Plate-specific conclusions

This research layer should not contain:

• screenshots from vendor docs
• raw captured pages
• one-to-one source-card layers
• long source-shaped summaries
• quote-heavy mirrors of external docs

Rule of thumb:

• one source file -> one summary card = raw layer
• many source files -> one synthesized page = research layer

Promote durable knowledge only Copy Section

This research layer is not where every exploratory note goes.

Only promote content here when it is:

• reusable
• likely to matter again
• stable enough to deserve a home
• clearer as a maintained page than as one-off chat or scratch analysis

Leave temporary exploration in docs/analysis or docs/plans.

Coverage gaps are expected unless agents maintain them proactively Copy Section

This research layer will fail if agents only update it reactively from the narrow task in
front of them.

Failure modes:

• a task touches only one source, but other relevant raw evidence in ../raw
  never gets ingested
• a raw source exists, but no compiled source page was ever written
• a compiled page exists, but the relevant decision or concept page was never
  updated
• the agent answers from the visible local slice and misses a gap somewhere
  else in the corpus

So the maintenance model cannot be "update whatever file the current task
happened to mention." That is how holes accumulate.

Page types Copy Chapter

`commands/` Copy Section

Operational command specs for repeatable agent workflows.

Use this for:

• full research passes
• maintenance passes
• gap-detection workflows
• ingest workflows

Do not use it to store domain knowledge itself.

`schema.md` Copy Section

The minimal metadata contract for page types in this layer.

Keep it small and stable.

`index.md` Copy Section

The entrypoint catalog.

This is what an agent should read first.

It should answer:

• what exists
• where it lives
• what each page is for

`log.md` Copy Section

Append-only history of meaningful wiki operations.

Use it for:

• new source ingests
• important restructures
• lint passes
• major corrections

Do not turn it into a second index.

`sources/` Copy Section

Compiled summaries of raw evidence.

Each source summary should say:

• what the source is
• what it added
• what it confirmed
• what it contradicted
• what compiled pages it should affect

This is where source-specific work belongs. If a page still mostly smells like
"what this source said", it probably belongs in sources/.

`decisions/` Copy Section

Canonical repo-relevant choices.

These pages should say:

• the question
• the chosen answer
• the reason
• competing options
• source refs
• blast radius

If a page answers "what won?", it belongs in decisions/.

`concepts/` Copy Section

Shared vocabulary and abstractions.

These pages should say:

• what the term means
• what it is not
• where it is used

If a page answers "what does this idea mean across the repo?", it belongs in
concepts/.

`systems/` Copy Section

Architecture or authority maps.

These pages should say:

• boundaries
• ownership
• important internal links
• how to navigate the area

If a page answers "how does this whole area fit together?", it belongs in
systems/.

`entities/` Copy Section

Concrete named things.

Examples:

• editors
• reference products
• Plate packages
• plugins

If a page is about one concrete named thing, it belongs in entities/.

`open-questions/` Copy Section

Known ambiguity that should not be silently “resolved” by agent confidence.

Use this to preserve real uncertainty.

If a page answers "we still do not know", it belongs in open-questions/.

Relationship To Other Docs Copy Chapter

This repo should use three different layers for three different jobs.

`docs/analysis` Copy Section

Scratch and exploratory thinking.

Use it for:

• workbench comparisons
• candidate lists
• ranking drafts
• architecture exploration
• temporary synthesis that is not stable yet

This is where something like
editor-architecture-candidates.md
starts.

`docs/research` Copy Section

Compiled reusable knowledge.

Use it for:

• source summaries worth keeping
• reusable concept pages
• architecture maps worth reusing
• entity pages that future agents will need
• explicit decisions

This is the research brain.

`docs/editor-behavior` Copy Section

Normative law and ship gate.

Use it for:

• authority model
• behavior law
• exhaustive protocol rows
• release gating

This is the law layer, not the research archive.

Rule Of Thumb Copy Section

• docs/analysis = exploratory
• docs/research = compiled reusable knowledge
• docs/editor-behavior = normative spec

Do not make one directory do all three jobs.

Migration Rules Copy Chapter

When migrating existing docs into the research layer:

1. do not move a file just because it exists
2. first ask what job the file is doing:
   • scratch exploration
   • compiled knowledge
   • normative law
3. only move it into docs/research if it is durable compiled knowledge

Good migration examples Copy Section

• a source-heavy comparison doc becomes:
  • one systems/... page
  • several entities/... pages
  • maybe a few decisions/... pages
• repeated terminology explanations become concepts/...
• repeated product or repo summaries become entities/...

Bad migration examples Copy Section

• dumping docs/analysis/* wholesale into docs/research
• copying docs/editor-behavior/* into docs/research just to have a second copy
• making one giant "Slate v2 + Plate v2 + plugins + references" page

Specific guidance for architecture work Copy Section

Something like
editor-architecture-candidates.md
should not be copied as one giant research page.

Its durable parts should decompose into pages like:

• systems/editor-architecture-landscape.md
• entities/prosemirror.md
• entities/lexical.md
• entities/slate.md
• entities/tiptap.md
• later, if needed, decisions/... pages for explicit Plate choices

Core operations Copy Chapter

Ingest Copy Section

When new evidence arrives:

1. read the raw source
2. classify what it affects
3. write or update a source summary
4. update any impacted decision, concept, system, or entity pages
5. update index.md
6. append log.md

Ingest alone is not enough. It only handles known sources that were already
noticed.

Query Copy Section

When answering a task:

1. start from index.md
2. read the relevant compiled pages
3. answer from the compiled research layer first
4. verify against raw evidence when needed

Lint Copy Section

Periodically check for:

• stale claims
• duplicated concepts
• orphan pages
• dead terminology
• contradictions
• overgrown pages that should be split
• open questions that now have answers

Lint should also detect coverage gaps, not just stale wording.

Autonomous Maintenance Copy Chapter

This research layer should eventually be maintained by a dedicated autonomous skill or
workflow, not only by incidental task work.

Its job is to proactively improve both layers:

• the private raw evidence layer in ../raw
• the compiled layer in docs/research

Why this is needed Copy Section

If the user asks a question about a goal area and the relevant evidence was
never ingested or compiled, the agent may miss the answer entirely.

That means the system must support:

• gap detection
• proactive ingest
• proactive compilation
• targeted refresh

without waiting for a human to notice every missing page manually.

Recommended skill shape Copy Section

The right future skill is something like:

• research-maintainer
• or research-gap-filler

Its mission is not just to summarize.
Its mission is to keep the reference system complete enough that future agents
do not fall through obvious holes.

Inputs Copy Section

The skill should accept a goal, area, or question such as:

• editor behavior references
• plate v2 architecture
• slate v2 risks
• plugin model

Loop Copy Section

Given a goal, the skill should:

1. infer the likely entities, systems, concepts, and decisions involved
2. scan docs/research for existing compiled coverage
3. scan ../raw for relevant raw evidence
4. classify gaps:
   • raw missing
   • raw exists but compiled summary missing
   • compiled summary exists but decision/concept/system pages missing
   • stale compiled pages
   • contradictions between compiled pages
   • weakly sourced claims
5. fill the highest-value gaps it can safely fill
6. record what it changed in log.md
7. leave explicit open-questions/... pages where the gap cannot be filled yet

Gap classes Copy Section

Use these gap classes explicitly:

• Raw gap: no relevant evidence exists in ../raw
• Compile gap: raw evidence exists, but docs/research/sources/... is missing
• Synthesis gap: source summaries exist, but no concept/system/decision page
  captures the reusable conclusion
• Freshness gap: compiled page exists, but newer evidence likely changed it
• Contradiction gap: two compiled pages disagree or point in different
  directions
• Structure gap: pages exist, but they are duplicated, orphaned, or split
  at the wrong boundaries

Safe autofill rules Copy Section

The skill should be aggressive about structure and conservative about claims.

Safe actions:

• create missing source summary pages from existing raw evidence
• add missing backlinks and index.md entries
• split giant mixed pages into clearer page types
• create entity or concept stubs when the source support is obvious
• open explicit question pages when evidence is still thin

Unsafe actions that need stronger evidence:

• inventing decisions without source support
• claiming coverage where only one weak source exists
• silently resolving contradictions
• creating fake completeness from repo-local vibes

Output Copy Section

Each run should leave:

• updated research pages
• updated index.md
• appended log.md
• explicit open questions for unresolved gaps

And, when useful, a concise gap report saying:

• what was missing
• what was filled
• what still needs raw evidence

Trigger points Copy Section

This maintenance skill should be used:

• before major research or migration tasks
• after finishing major research or migration tasks
• periodically as a research health pass
• whenever an agent notices it is answering from thin or incomplete coverage

Rule of thumb Copy Section

If the current task depends on a domain that feels bigger than the currently
visible pages, do not trust the visible pages alone.

Run a gap-detection pass first.

Retrieval order Copy Chapter

The default retrieval order is:

1. docs/research
2. primary raw evidence in ../raw
3. broader repo search
4. external sources if still needed

If an agent searches the whole repo before checking docs/research, this layer is
failing its job.

Operational Surface Copy Chapter

The commands in commands/ are the executable mental model for applying this
research layer in practice.

Start with:

• commands/full-pipeline.md
• commands/maintain.md

That is the heavyweight command for improving the research layer from a goal or
domain instead of answering only from the currently visible slice.

Use schema.md to keep page
metadata consistent while the layer is still small.

Initial scope Copy Chapter

Start with one narrow evidence corpus from ../raw, prove the ingest and
retrieval workflow, then expand to additional sources only after the first path
is stable.

Agent rules Copy Chapter

• never edit ../raw while compiling conclusions unless the task is explicitly
  about curating raw evidence
• never add a durable claim here without evidence
• never flatten contradictions into fake certainty
• never treat compiled summaries as stronger than primary sources
• never let a reusable analysis die in chat if it belongs in this research layer

Overview (`packages/ai/README.md`) Copy Section

Plate ai

Visit https://platejs.org/docs/ai to view the documentation.

License Copy Chapter

MIT

Overview (`packages/basic-nodes/README.md`) Copy Section

Plate basic elements plugin

This package implements the basic elements in a single plugin:

• block quote
• code block
• heading
• paragraph

Documentation Copy Chapter

Check out
Basic Elements.

License Copy Chapter

MIT

Overview (`packages/basic-styles/README.md`) Copy Section

Plate basic styles

Visit https://platejs.org/docs/text-align to view the documentation.

License Copy Chapter

MIT

Overview (`packages/callout/README.md`) Copy Section

Plate callout plugins

This package implements the callout block plugins for Plate.

License Copy Chapter

MIT

Overview (`packages/code-block/README.md`) Copy Section

Plate code block plugin

This package implements the code block plugin for Plate.

Documentation Copy Chapter

Check out
Basic Elements.

License Copy Chapter

MIT

Overview (`packages/code-drawing/README.md`) Copy Section

Plate code-drawing plugin

This package implements the code-drawing plugin for Plate, supporting PlantUml, Graphviz, Flowchart, and Mermaid diagrams.

Documentation Copy Chapter

Check out Code Drawing.

License Copy Chapter

MIT

Overview (`packages/combobox/README.md`) Copy Section

Plate combobox

This package implements the combobox for Plate.

Documentation Copy Chapter

Check out Playground and
Combobox.

License Copy Chapter

MIT

Overview (`packages/comment/README.md`) Copy Section

Plate comments plugin

This package implements the comments plugin for Plate.

Documentation Copy Chapter

Check out comments.

License Copy Chapter

MIT

Overview (`packages/core/README.md`) Copy Section

Plate Core

This package provides the foundational structure of the Plate editor framework.

Documentation Copy Chapter

Visit https://platejs.org/docs/api/core to view the documentation.

License Copy Chapter

MIT

Overview (`packages/csv/README.md`) Copy Section

Plate CSV serializer plugin

This package implements the CSV serializer for Plate.

Documentation Copy Chapter

Check out Playground.

License Copy Chapter

MIT

Overview (`packages/cursor/README.md`) Copy Section

Plate Cursor Overlay

This package implements a cursor overlay for Plate.

Documentation Copy Chapter

Check out
Cursor Overlay.

License Copy Chapter

MIT

Overview (`packages/date/README.md`) Copy Section

Plate date plugin

This package implements the date plugin for Plate.

Documentation Copy Chapter

Check out date.

License Copy Chapter

MIT

Overview (`packages/diff/README.md`) Copy Section

Compute a diff of two Slate documents

License Copy Chapter

See LICENSE

Overview (`packages/dnd/README.md`) Copy Section

Plate Drag & Drop

Visit https://platejs.org/docs/dnd to view the documentation.

License Copy Chapter

MIT

Overview (`packages/docx/README.md`) Copy Section

Plate Docx serializer plugin

This package implements the docx deserializer for Plate.

Documentation Copy Chapter

License Copy Chapter

MIT

Overview (`packages/emoji/README.md`) Copy Section

Plate emoji plugin

This package implements the emoji plugin for Plate.

Documentation Copy Chapter

Check out Emoji.

License Copy Chapter

MIT

Overview (`packages/excalidraw/README.md`) Copy Section

Plate excalidraw plugin

This package implements the excalidraw plugin for Plate.

Documentation Copy Chapter

Check out
Excalidraw.

License Copy Chapter

MIT

Overview (`packages/find-replace/README.md`) Copy Section

Plate find and replace plugin

This package implements the find and replace plugin for Plate.

Documentation Copy Chapter

Check out Find & Replace.

License Copy Chapter

MIT

Overview (`packages/floating/README.md`) Copy Section

Plate floating UI

This package implements the floating UI for Plate.

Documentation Copy Chapter

See Link, Mention.

License Copy Chapter

MIT

Overview (`packages/footnote/README.md`) Copy Section

@platejs/footnote

Footnote plugins for Plate.

This package adds dedicated footnote reference and footnote definition nodes,
plus transforms and queries for inserting, resolving, navigating, and repairing
footnotes.

Features Copy Chapter

• Parse GFM footnote references and definitions into Plate nodes
• Serialize footnote nodes back to markdown footnotes
• Insert a reference and matching definition with one transform
• Allocate the next free numeric identifier automatically
• Create a missing definition for an unresolved reference
• Detect and repair later duplicate definitions
• Navigate between references and definitions

Installation Copy Chapter

npm install @platejs/footnote @platejs/markdown remark-gfm

Usage Copy Chapter

import {
  FootnoteDefinitionPlugin,
  FootnoteReferencePlugin,
} from '@platejs/footnote/react';
import { MarkdownPlugin } from '@platejs/markdown';
import { createPlateEditor } from 'platejs/react';
import remarkGfm from 'remark-gfm';

const editor = createPlateEditor({
  plugins: [
    FootnoteReferencePlugin,
    FootnoteDefinitionPlugin,
    MarkdownPlugin.configure({
      options: {
        remarkPlugins: [remarkGfm],
      },
    }),
  ],
});

Package Surface Copy Chapter

Queries:

• api.footnote.nextId
• api.footnote.definition
• api.footnote.definitions
• api.footnote.definitionText
• api.footnote.duplicateDefinitions
• api.footnote.duplicateIdentifiers
• api.footnote.hasDuplicateDefinitions
• api.footnote.isDuplicateDefinition
• api.footnote.isResolved
• api.footnote.references

Transforms:

• tf.insert.footnote
• tf.footnote.createDefinition
• tf.footnote.focusDefinition
• tf.footnote.focusReference
• tf.footnote.normalizeDuplicateDefinition

Documentation Copy Chapter

• Footnote docs: https://platejs.org/docs/footnote
• Markdown docs: https://platejs.org/docs/markdown

License Copy Chapter

MIT

Overview (`packages/indent/README.md`) Copy Section

Plate block indentation plugin

This package implements block indentation support for Plate.

Documentation Copy Chapter

Check out Indentation.

License Copy Chapter

MIT

Overview (`packages/juice/README.md`) Copy Section

Plate juice plugin

This package implements the juice plugin for Plate.

Given inserted HTML, juice will inline the CSS properties into the style attribute.

Documentation Copy Chapter

Check out
Serializing HTML.

License Copy Chapter

MIT

Overview (`packages/link/README.md`) Copy Section

Plate link plugin

This package implements the link plugin for Plate.

Documentation Copy Chapter

Check out Link.

License Copy Chapter

MIT

Overview (`packages/list-classic/README.md`) Copy Section

Plate list plugin

This package implements the list plugin for Plate.

Documentation Copy Chapter

Check out List.

License Copy Chapter

MIT

Overview (`packages/list/README.md`) Copy Section

Plate indent list plugin

This package implements the indent list plugin for Plate.
It's a mix of indent and list plugins, also called as a "flat list"
because the list structure has no children.

Documentation Copy Chapter

Check out List.

License Copy Chapter

MIT

Overview (`packages/markdown/README.md`) Copy Section

Plate MD serializer plugin

This package implements the Markdown serializer for Plate.

Documentation Copy Chapter

Check out
Serializing Markdown.

License Copy Chapter

MIT

Overview (`packages/math/README.md`) Copy Section

Plate math plugin

This package implements the math plugin for Plate.

Documentation Copy Chapter

Check out math.

License Copy Chapter

MIT

Overview (`packages/media/README.md`) Copy Section

Plate media plugins

This package implements the media plugins for Plate. It allows inserting
embeddable media such as images, YouTube or Vimeo videos and tweets into your
editor.

Includes:

• caption
• resizable
• media
• image
• iframe

Documentation Copy Chapter

• Check out Media.

License Copy Chapter

MIT

Overview (`packages/mention/README.md`) Copy Section

Plate mention plugin

This package implements the mention plugin for Plate. It allows
autocompletion from user input.

Documentation Copy Chapter

Check out Mention.

License Copy Chapter

MIT

Overview (`packages/playwright/README.md`) Copy Section

Interact with a Plate editor from inside a Playwright test

License Copy Chapter

See LICENSE

Overview (`packages/selection/README.md`) Copy Section

Plate plugin for block selection

Plugin that allows you to select blocks in the drag area using the mouse or touch.

Documentation Copy Chapter

Check out
Block Selection.

License Copy Chapter

MIT

Overview (`packages/slash-command/README.md`) Copy Section

Plate slash commands plugin

This package implements the slash commands plugin for Plate.

License Copy Chapter

MIT

Overview (`packages/slate/README.md`) Copy Section

Slate extension

Documentation Copy Chapter

Visit https://platejs.org/docs/api/slate to view the documentation.

License Copy Chapter

MIT

Overview (`packages/suggestion/README.md`) Copy Section

Plate plugin for suggestion

License Copy Chapter

MIT

Overview (`packages/tabbable/README.md`) Copy Section

Plate tabbable plugin

This package programmatically corrects the tab order for tabbable elements inside the editor

Documentation Copy Chapter

Check out
Tabbable.

License Copy Chapter

MIT

Overview (`packages/table/README.md`) Copy Section

Plate table plugin

This package implements the table plugin for Plate.

Documentation Copy Chapter

Check out Table.

License Copy Chapter

MIT

Overview (`packages/tag/README.md`) Copy Section

Plate tag plugin

This package implements the tag plugin for Plate.

Documentation Copy Chapter

Check out Tag.

License Copy Chapter

MIT

Overview (`packages/test-utils/README.md`) Copy Section

Plate test utilities

This package implements the test utilities for Plate.

License Copy Chapter

MIT

Overview (`packages/toc/README.md`) Copy Section

Table of Contents plugin

This package implements the table of contents plugin for Plate.

Documentation Copy Chapter

Check out
Table of Contents.

License Copy Chapter

MIT

Overview (`packages/toggle/README.md`) Copy Section

Plate toggle plugin

This package implements the toggle plugin for Plate.
It's similar to the indent list plugin, in that it relies on the indent of siblings.

Documentation Copy Chapter

Check out Toggle.

Ideas to improve this plugin Copy Chapter

1. Adding an option initialValue of open toggleIds and a callback onChange, for instance to store the state of open toggles in local storage and remember the state upon browser refresh.
2. Adding an option defaultOpen. Currently, toggles are closed on initial rendering.
3. Adding an option to specify how to get the indent value of elements, right now we are relying on this being the default KEY_ELEMENT from the indent plugin
4. An option to specify how to get the id of elements, right now we are using the default id attribute from the node-id plugin.
5. Adding a placeholder below the toggle, like Notion does, when the toggle is expanded without any elements below.
6. Make toggle button more accessible
7. When indenting an element right of a closed toggle, it becomes hidden. This makes sense, but a nicer UI would be to open the toggle in that case, like Notion does.

License Copy Chapter

MIT

Overview (`packages/utils/README.md`) Copy Section

Plate utils

Documentation Copy Chapter

Visit https://platejs.org/docs/api/utils to view the documentation.

License Copy Chapter

MIT

Overview (`packages/yjs/README.md`) Copy Section

Plate Yjs plugin

@platejs/yjs binds Plate editors to a shared Yjs document. It ships provider wrappers for IndexedDB, Hocuspocus, and WebRTC, and accepts custom providers that implement the same UnifiedProvider interface.

Read the main docs at platejs.org/docs/yjs.

Installation Copy Chapter

Install the plugin.

npm install @platejs/yjs

Install network provider packages as needed:

npm install @hocuspocus/provider

npm install y-webrtc

Usage Copy Chapter

Configure YjsPlugin with a providers array. Every configured provider receives the same plugin-owned Y.Doc and Awareness instance.

import { YjsPlugin } from '@platejs/yjs/react';
import { createPlateEditor } from 'platejs/react';

const editor = createPlateEditor({
  plugins: [
    YjsPlugin.configure({
      options: {
        providers: [
          {
            type: 'indexeddb',
            options: {
              docName: 'document-1',
            },
          },
          {
            type: 'hocuspocus',
            options: {
              name: 'document-1',
              url: 'wss://collab.example.com',
            },
          },
          {
            type: 'webrtc',
            options: {
              roomName: 'document-1',
            },
          },
        ],
      },
    }),
  ],
  skipInitialization: true,
});

Call init after the editor mounts, and call destroy when it unmounts:

await editor.getApi(YjsPlugin).yjs.init({
  id: 'document-1',
  value: initialValue,
});

editor.getApi(YjsPlugin).yjs.destroy();

Providers Copy Chapter

Use the same document identifier across providers that should share one document. For example, pair docName: 'document-1' with name: 'document-1' or roomName: 'document-1'.

IndexedDB only persists Yjs updates locally. It does not transport awareness, cursors, or remote users; combine it with Hocuspocus or WebRTC for multi-user collaboration.

Shared Documents Copy Chapter

Pass ydoc when another part of your app owns the document:

import * as Y from 'yjs';

const ydoc = new Y.Doc();

YjsPlugin.configure({
  options: {
    ydoc,
    providers: [
      {
        type: 'indexeddb',
        options: {
          docName: 'document-1',
        },
      },
    ],
  },
});

Use sharedType when the editor content lives inside a nested Y.XmlText:

const parentDoc = new Y.Doc();
const editors = parentDoc.getMap('editors');
const mainContent = new Y.XmlText();

editors.set('main', mainContent);

YjsPlugin.configure({
  options: {
    sharedType: mainContent,
    ydoc: parentDoc,
    providers: [
      {
        type: 'indexeddb',
        options: {
          docName: 'document-1',
        },
      },
    ],
  },
});

Custom Providers Copy Chapter

Use a pre-instantiated provider directly when you need behavior outside the built-in wrappers:

import type { UnifiedProvider } from '@platejs/yjs';

const provider: UnifiedProvider = new MyProvider({ awareness, doc: ydoc });

YjsPlugin.configure({
  options: {
    providers: [provider],
  },
});

Register reusable provider classes with registerProviderType:

import { registerProviderType } from '@platejs/yjs';

registerProviderType('custom', CustomProviderWrapper);

YjsPlugin.configure({
  options: {
    providers: [
      {
        type: 'custom',
        options: {
          roomName: 'document-1',
        },
      },
    ],
  },
});

License Copy Chapter

MIT

Overview (`templates/plate-playground-template/README.md`) Copy Section

Playground Template

A Next.js template with Plate AI, plugins and components.

Features Copy Chapter

• Next.js 16
• Plate editor
• shadcn/ui
• MCP

Requirements Copy Chapter

• Node.js 20+
• bun

Installation Copy Chapter

Choose one of these methods:

1. Using CLI (Recommended) Copy Section

npx shadcn@latest add @plate/editor-ai

2. Using Template Copy Section

Use this template, then install dependencies:

bun install

Development Copy Chapter

Copy the example env file:

cp .env.example .env.local

Configure .env.local:

• UPLOADTHING_TOKEN – UploadThing API key (get one here)

Enter your own AI Gateway key in the editor settings to use AI. The example API routes use the caller's key.

Uploads work in local development. Before enabling production uploads, replace the development check in src/lib/uploadthing.ts with your application's session and permission checks. Add per-user upload limits.

If your application uses a shared server AI credential, authorize each request and enforce per-user usage limits before calling the provider. Keep server credentials out of client code.

Start the development server:

bun dev

Visit http://localhost:3000/editor to see the editor in action.

Overview (`templates/plate-template/README.md`) Copy Section

Playground Template

A minimal template for building rich-text editors with Plate and Next.js.

Features Copy Chapter

• Next.js 16
• Plate editor
• shadcn/ui
• MCP

Requirements Copy Chapter

• Node.js 20+
• bun

Installation Copy Chapter

Choose one of these methods:

1. Using CLI (Recommended) Copy Section

npx shadcn@latest add @plate/editor-basic

2. Using Template Copy Section

Use this template, then install dependencies:

bun install

Development Copy Chapter

bun dev

Visit http://localhost:3000/editor to see the editor in action.

Upgrade Copy Chapter

Using the CLI, you can upgrade to editor-ai by running:

npx shadcn@latest add @plate/editor-ai -o

Overview (`tooling/cn/README.md`) Copy Section

Plate

模板 Copy Chapter

您可以选择以下模板之一开始使用：

文档 Copy Chapter

您可以通过查看我们的文档了解更多关于Plate的信息。

贡献 Copy Chapter

要开始贡献，请查看我们的贡献指南。

贡献者 Copy Section

我们希望您能加入我们！无论是给我们一个🌟星标，提交一个📥拉取请求，还是分享您的插件，您的帮助总是值得称赞的。

需要更多帮助？加入我们的Discord。我们随时为您提供指导。(可以在中文频道使用中文进行提问)

Overview (`.agents/skills/autogoal/README.md`) Copy Section

Autogoal

Autogoal asks Codex to write a goal-backed plan ending with autoreview.

Install Copy Chapter

npx skills add udecode/dotai --skill autogoal

Use Copy Chapter

Use autogoal for non-trivial work with an auditable finish line:

• debugging loops
• migrations
• benchmarks
• architecture plans
• pass-gated reviews
• multi-step issue work

Skip it for one-off answers, typo fixes, or tiny edits where the final response
can carry the evidence.

Flow Copy Chapter

1. Define the outcome, completion threshold, verification surface, constraints,
   boundaries, and blocked condition.
2. Create or continue the active Codex goal with a short objective handle.
3. Create a plan from a built-in or project template and put the full contract
   there.
4. First checkpoint: copy every explicit prompt requirement into the plan as
   checkable rows before implementation.
5. Work in slices and record evidence as you go.
6. Run autoreview, then fix or record accepted findings.
7. Run the completion check.
8. Mark the goal complete only when the outcome is true and the plan passes.

Helpers Copy Chapter

node .agents/skills/autogoal/scripts/create-goal-scratchpad.mjs \
  --template task \
  --with browser \
  --title "short title"

node .agents/skills/autogoal/scripts/check-complete.mjs docs/plans/<plan>.md

node .agents/skills/autogoal/scripts/init-templates.mjs

Templates Copy Chapter

Autogoal ships generic templates in skills/autogoal/assets/templates.
Installed skills expose them under .agents/skills/autogoal/assets/templates.

Project repos can keep their own templates in docs/plans/templates; the helper
prefers project templates before built-in templates.

Overview (`.agents/skills/react-useeffect/README.md`) Copy Section

React useEffect Best Practices

A comprehensive guide teaching when to use useEffect in React, and more importantly, when NOT to use it. This skill is based on official React documentation and provides practical alternatives to common useEffect anti-patterns.

Purpose Copy Chapter

Effects are an escape hatch from React's reactive paradigm. They let you synchronize with external systems like browser APIs, third-party widgets, or network requests. However, many developers overuse Effects for tasks that React handles better through other means.

This skill helps you:

• Identify when you truly need an Effect vs. when you don't
• Recognize common anti-patterns and their fixes
• Apply better alternatives like useMemo, key prop, and event handlers
• Write Effects that are clean, maintainable, and free from race conditions

When to Use This Skill Copy Chapter

Use this skill when you're:

• Writing or reviewing useEffect code
• Using useState to store derived values
• Implementing data fetching or subscriptions
• Synchronizing state between components
• Facing bugs with stale data or race conditions
• Wondering if your Effect is necessary

Trigger phrases:

• "Should I use useEffect for this?"
• "How do I fix this useEffect?"
• "My Effect is causing too many re-renders"
• "Data fetching with useEffect"
• "Reset state when props change"
• "Derived state from props"

How It Works Copy Chapter

This skill provides guidance through three key resources:

1. Quick Reference Table - Fast lookup for common scenarios with DO/DON'T patterns
2. Decision Tree - Visual flowchart to determine the right approach
3. Detailed Anti-Patterns - 9 common mistakes with explanations and fixes
4. Better Alternatives - 8 proven patterns to replace unnecessary Effects

The skill teaches you to ask the right questions:

• Is there an external system involved?
• Am I responding to a user event or component appearance?
• Can this value be calculated during render?
• Do I need to reset state when a prop changes?

Key Features Copy Chapter

1. Quick Reference Guide Copy Section

Visual table showing the DO/DON'T for common scenarios:

• Derived state from props/state
• Expensive calculations
• Resetting state on prop change
• User event responses
• Notifying parent components
• Data fetching

2. Decision Tree Copy Section

Clear flowchart that guides you from "Need to respond to something?" to the correct solution:

• User interaction → Event handler
• Component appeared → Effect (for external sync/analytics)
• Derived value needed → Calculate during render (+ useMemo if expensive)
• Reset state on prop change → Key prop

3. Anti-Pattern Recognition Copy Section

Detailed examples of 9 common mistakes:

1. Redundant state for derived values
2. Filtering/transforming data in Effect
3. Resetting state on prop change
4. Event-specific logic in Effect
5. Chains of Effects
6. Notifying parent via Effect
7. Passing data up to parent
8. Fetching without cleanup (race conditions)
9. App initialization in Effect

Each anti-pattern includes:

• Bad example with explanation
• Good example with fix
• Why the anti-pattern is problematic

4. Better Alternatives Copy Section

8 proven patterns to replace unnecessary Effects:

1. Calculate during render for derived state
2. useMemo for expensive calculations
3. key prop to reset state
4. Store ID instead of object for stable references
5. Event handlers for user actions
6. useSyncExternalStore for external stores
7. Lifting state up for shared state
8. Custom hooks for data fetching with cleanup

Usage Examples Copy Chapter

Example 1: Derived State Copy Section

Bad - Unnecessary Effect:

function Form() {
  const [firstName, setFirstName] = useState('Taylor');
  const [lastName, setLastName] = useState('Swift');
  const [fullName, setFullName] = useState('');

  useEffect(() => {
    setFullName(firstName + ' ' + lastName);
  }, [firstName, lastName]);
}

Good - Calculate during render:

function Form() {
  const [firstName, setFirstName] = useState('Taylor');
  const [lastName, setLastName] = useState('Swift');
  const fullName = firstName + ' ' + lastName; // Just compute it
}

Example 2: Resetting State Copy Section

Bad - Effect to reset:

function ProfilePage({ userId }) {
  const [comment, setComment] = useState('');

  useEffect(() => {
    setComment('');
  }, [userId]);
}

Good - Key prop:

function ProfilePage({ userId }) {
  return <Profile userId={userId} key={userId} />;
}

function Profile({ userId }) {
  const [comment, setComment] = useState(''); // Resets automatically
}

Example 3: Data Fetching with Cleanup Copy Section

Bad - Race condition:

function SearchResults({ query }) {
  const [results, setResults] = useState([]);

  useEffect(() => {
    fetchResults(query).then(json => {
      setResults(json); // "hello" response may arrive after "hell"
    });
  }, [query]);
}

Good - Cleanup flag:

function SearchResults({ query }) {
  const [results, setResults] = useState([]);

  useEffect(() => {
    let ignore = false;

    fetchResults(query).then(json => {
      if (!ignore) setResults(json);
    });

    return () => { ignore = true; };
  }, [query]);
}

Example 4: Event Handler Instead of Effect Copy Section

Bad - Effect watching state:

function ProductPage({ product, addToCart }) {
  useEffect(() => {
    if (product.isInCart) {
      showNotification(`Added ${product.name}!`);
    }
  }, [product]);

  function handleBuyClick() {
    addToCart(product);
  }
}

Good - Handle in event:

function ProductPage({ product, addToCart }) {
  function handleBuyClick() {
    addToCart(product);
    showNotification(`Added ${product.name}!`);
  }
}

When You DO Need Effects Copy Chapter

Effects are appropriate for:

• Synchronizing with external systems - Browser APIs, third-party widgets, non-React code
• Subscriptions - WebSocket connections, global event listeners (prefer useSyncExternalStore)
• Analytics/logging - Code that needs to run because the component displayed
• Data fetching - With proper cleanup (or use your framework's built-in mechanism)

When You DON'T Need Effects Copy Chapter

Avoid Effects for:

1. Transforming data for rendering - Calculate at the top level instead
2. Handling user events - Use event handlers where you know exactly what happened
3. Deriving state - Just compute it: const fullName = firstName + ' ' + lastName
4. Chaining state updates - Calculate all next state in the event handler
5. Notifying parent components - Call the callback in the same event handler
6. Resetting state - Use the key prop to create a fresh component instance

Best Practices Copy Chapter

1. Start Without an Effect Copy Section

Before adding an Effect, ask: "Is there an external system involved?" If no, you probably don't need an Effect.

2. Prefer Derived State Copy Section

If you can calculate a value from props or state, don't store it in state with an Effect updating it.

3. Use the Right Tool Copy Section

• Expensive calculation → useMemo
• User interaction → Event handler
• Reset on prop change → key prop
• External subscription → useSyncExternalStore
• Shared state → Lift state up

4. Always Clean Up Copy Section

If your Effect subscribes, fetches, or sets timers, return a cleanup function to prevent memory leaks and race conditions.

5. Avoid Effect Chains Copy Section

Multiple Effects triggering each other causes unnecessary re-renders and makes code hard to follow. Calculate everything in one place (usually an event handler).

6. Test in Strict Mode Copy Section

React 18+ Strict Mode mounts components twice in development to expose missing cleanup. If your Effect breaks, you need cleanup.

7. Consider Framework Solutions Copy Section

For data fetching, prefer your framework's built-in solution (Next.js, Remix) or libraries (React Query, SWR) over manual Effects.

Reference Files Copy Chapter

This skill includes three detailed reference documents:

1. SKILL.md - Quick reference table and decision tree
2. anti-patterns.md - 9 common mistakes with detailed explanations
3. alternatives.md - 8 better alternatives with code examples

Common Pitfalls Copy Chapter

Multiple Re-renders Copy Section

Symptom: Component re-renders many times in quick succession.

Cause: Effect that sets state based on state it depends on, creating a loop.

Fix: Calculate the final value in an event handler or during render.

Stale Data Copy Section

Symptom: UI shows outdated values briefly before updating.

Cause: Using Effect to update derived state causes an extra render pass.

Fix: Calculate derived values during render instead of in state.

Race Conditions Copy Section

Symptom: Fast typing shows results for old queries after new ones.

Cause: Missing cleanup in data fetching Effect.

Fix: Use cleanup flag (ignore variable) or AbortController.

Runs Twice in Development Copy Section

Symptom: Effect runs twice on component mount in development.

Cause: React 18 Strict Mode intentionally mounts components twice to expose bugs.

Fix: Add proper cleanup. If it's app initialization that shouldn't run twice, use a module-level guard.

Resources Copy Chapter

This skill is based on:

• React Official Docs: You Might Not Need an Effect
• React Official Docs: Synchronizing with Effects
• React Official Docs: Lifecycle of Reactive Effects

Summary Copy Chapter

The golden rule: Effects are an escape hatch from React. If you're not synchronizing with an external system, you probably don't need an Effect.

Before writing useEffect, ask yourself:

1. Is this responding to a user interaction? → Use event handler
2. Is this a value I can calculate from props/state? → Calculate during render
3. Is this resetting state when a prop changes? → Use key prop
4. Is this synchronizing with an external system? → Use Effect with cleanup

Follow these patterns, and your React code will be more maintainable, performant, and bug-free.

Overview (`.agents/skills/vercel-react-best-practices/README.md`) Copy Section

React Best Practices

A structured repository for creating and maintaining React Best Practices optimized for agents and LLMs.

Structure Copy Chapter

• rules/ - Individual rule files (one per rule)
  • _sections.md - Section metadata (titles, impacts, descriptions)
  • _template.md - Template for creating new rules
  • area-description.md - Individual rule files
• src/ - Build scripts and utilities
• metadata.json - Document metadata (version, organization, abstract)
• AGENTS.md - Compiled output (generated)
• test-cases.json - Test cases for LLM evaluation (generated)

Getting Started Copy Chapter

1. Install dependencies:

   bash Copy

   pnpm install

2. Build AGENTS.md from rules:

   bash Copy

   pnpm build

3. Validate rule files:

   bash Copy

   pnpm validate

4. Extract test cases:

   bash Copy

   pnpm extract-tests

Creating a New Rule Copy Chapter

1. Copy rules/_template.md to rules/area-description.md
2. Choose the appropriate area prefix:
   • async- for Eliminating Waterfalls (Section 1)
   • bundle- for Bundle Size Optimization (Section 2)
   • server- for Server-Side Performance (Section 3)
   • client- for Client-Side Data Fetching (Section 4)
   • rerender- for Re-render Optimization (Section 5)
   • rendering- for Rendering Performance (Section 6)
   • js- for JavaScript Performance (Section 7)
   • advanced- for Advanced Patterns (Section 8)
3. Fill in the frontmatter and content
4. Ensure you have clear examples with explanations
5. Run pnpm build to regenerate AGENTS.md and test-cases.json

Rule File Structure Copy Chapter

Each rule file should follow this structure:

---
title: Rule Title Here
impact: MEDIUM
impactDescription: Optional description
tags: tag1, tag2, tag3
---

## Rule Title Here

Brief explanation of the rule and why it matters.

**Incorrect (description of what's wrong):**

```typescript
// Bad code example

Correct (description of what's right):

// Good code example

Optional explanatory text after examples.

Reference: Link

File Naming Convention Copy Chapter

• Files starting with _ are special (excluded from build)
• Rule files: area-description.md (e.g., async-parallel.md)
• Section is automatically inferred from filename prefix
• Rules are sorted alphabetically by title within each section
• IDs (e.g., 1.1, 1.2) are auto-generated during build

Impact Levels Copy Chapter

• CRITICAL - Highest priority, major performance gains
• HIGH - Significant performance improvements
• MEDIUM-HIGH - Moderate-high gains
• MEDIUM - Moderate performance improvements
• LOW-MEDIUM - Low-medium gains
• LOW - Incremental improvements

Scripts Copy Chapter

• pnpm build - Compile rules into AGENTS.md
• pnpm validate - Validate all rule files
• pnpm extract-tests - Extract test cases for LLM evaluation
• pnpm dev - Build and validate

Contributing Copy Chapter

When adding or modifying rules:

1. Use the correct filename prefix for your section
2. Follow the _template.md structure
3. Include clear bad/good examples with explanations
4. Add appropriate tags
5. Run pnpm build to regenerate AGENTS.md and test-cases.json
6. Rules are automatically sorted by title - no need to manage numbers!

Acknowledgments Copy Chapter

Originally created by @shuding at Vercel.

Overview (`docs/editor-behavior/commands/README.md`) Copy Section

Editor Behavior Commands

This is the operator surface for resuming and maintaining
docs/editor-behavior.

Use it when you do not want to rediscover the workflow from scattered plans,
spec docs, and .omx artifacts.

This pack has two lanes:

• doc-governance:
  maintain standards, spec, protocol, parity, audit, and evidence truth
• implementation/runtime:
  choose, launch, and close real code/test/product batches from the roadmap

Canonical Artifacts Copy Chapter

• law stack:
  • markdown-standards.md
  • markdown-editing-spec.md
  • editor-protocol-matrix.md
  • markdown-parity-matrix.md
  • markdown-editing-reference-audit.md
• active execution notes:
  • 2026-04-02-editor-behavior-major-execution.md
  • 2026-04-03-editor-protocol-matrix-completion.md
• canonical remaining implementation roadmap:
  • master-roadmap.md
• active supporting implementation plans:
  • 2026-04-10-math-delimiter-trigger-implementation-plan.md
  • 2026-04-10-autoformat-runtime-alignment-and-extension-plan.md
  • 2026-04-09-date-media-expansion-consensus-plan.md
• historical OMX artifacts:
  • prd-editor-behavior-major.md
  • test-spec-editor-behavior-major.md
  • deep-interview-editor-behavior-major.md

Command Set Copy Chapter

Doc-Governance Lane Copy Section

• reconsolidate-law-stack.md
  Re-sync the standards/spec/protocol/parity/audit stack when truth drifted,
  including after runtime work changed behavior.
• refresh-evidence-ledger.md
  Refresh the evidence layer from research when doc truth or runtime planning is
  blocked on weak authority.
• reinterview-open-authority-gaps.md
  Re-open authority questions when the law stack cannot answer them and either
  doc maintenance or implementation planning is blocked by that ambiguity.

Implementation / Runtime Lane Copy Section

• replan-next-batch.md
  Turn current truth plus the roadmap into one concrete next runtime batch.
• launch-next-ralph-batch.md
  Execute the active approved runtime lane, not just the old major plan.

Fast Routing Copy Chapter

If You Are In A Doc-Governance Problem Copy Section

• If the docs disagree with each other, or a runtime batch changed behavior
  without the law stack catching up, start with
  reconsolidate-law-stack.md.
• If the audit or research feels stale, or an implementation lane is blocked on
  weak evidence, start with
  refresh-evidence-ledger.md.
• If the lane cannot answer “what should win here?”, “what next?”, or “what
  should move up/down in priority?”, run
  reinterview-open-authority-gaps.md
  before planning.

If You Are In An Implementation / Runtime Problem Copy Section

• After authority is clear and you need the next executable runtime slice, run
  replan-next-batch.md.
• If the gate is already closed but you still need the remaining backlog order
  or a narrower next slice, run
  replan-next-batch.md.
• When the next runtime batch is approved and concrete, run
  launch-next-ralph-batch.md.
• If runtime work exposes law drift, evidence debt, or unresolved authority,
  bounce back to the doc-governance lane instead of forcing more code work.

Overview (`docs/research/commands/README.md`) Copy Section

Research Commands

This directory contains command specs for operating the research layer.

Primary reusable entrypoint:

• $research-wiki

These pages are not knowledge pages like sources/ or concepts/.
They are operational docs that describe repeatable agent workflows.

Use them to define:

• full ingest-and-compile passes
• maintenance passes
• per-corpus completion rules for full mode
• official-source discovery checks before declaring corpus gaps
• local-raw exhaustiveness rules before declaring evidence gap

Current commands:

• full-pipeline.md
  The full-mode sub-workflow used by research-wiki.
• maintain.md
  The maintain-mode sub-workflow used by research-wiki.

Overview (`docs/research/concepts/README.md`) Copy Section

Concepts

This directory contains shared vocabulary and abstractions.

Each concept page should define one term cleanly and link to the systems,
decisions, entities, and sources that rely on it.

Current editor-architecture additions include:

• overlay-lane-separation.md
• durable-anchor-vs-live-handle.md
• runtime-identity-vs-tree-address.md
• source-scoped-overlay-invalidation.md

Overview (`docs/research/decisions/README.md`) Copy Section

Decisions

This directory contains normalized choices and policy calls.

Each decision page should answer:

• what question was decided
• what answer won
• why it won
• what it overruled
• what sources support it

Overview (`docs/research/entities/README.md`) Copy Section

Entities

This directory contains concrete named things.

Examples:

• editors like Typora or Obsidian
• reference products like Google Docs
• internal packages or plugins

Overview (`docs/research/open-questions/README.md`) Copy Section

Open Questions

This directory contains unresolved ambiguity that should stay explicit.

Use it when the evidence is mixed, thin, or incomplete.

Do not silently resolve those gaps in summary pages.

Overview (`docs/research/sources/README.md`) Copy Section

Sources

This directory contains compiled research summaries of raw evidence.

Each page here should summarize one raw source or one tightly related source
group from ../raw.

Do not store raw captures here.

Overview (`docs/research/systems/README.md`) Copy Section

Systems

This directory contains system maps and authority maps.

Use it for larger structures:

• editor-behavior authority models
• package or subsystem maps
• cross-editor comparison surfaces

Current editor-architecture pages include:

• editor-architecture-landscape.md
• slate-v2-overlay-architecture.md

Overview (`docs/slate-v2-draft/archive/README.md`) Copy Section

date: 2026-04-07 topic: slate-v2-archive-readme Copy Chapter

Slate v2 Archive

Archive only. Historical reference doc. For current queue and roadmap truth, see master-roadmap.md.

This folder keeps retired historical docs from the old docs/slate-v2 root
stack. These files are for archaeology, not the current replacement verdict.

Read these first instead:

• ../overview.md
• ../master-roadmap.md
• ../architecture-contract.md
• ../release-readiness-decision.md
• ../replacement-family-ledger.md
• ../full-replacement-blockers.md
• ../replacement-gates-scoreboard.md

Archive contents:

• historical benchmark and hardening writeups
• historical migration and compatibility writeups
• frozen roadmap and phase-plan artifacts
• older synthesis and status docs

Overview (`docs/slate-v2-draft/ledgers/README.md`) Copy Section

date: 2026-04-13 topic: slate-v2-exact-ledgers-index Copy Chapter

Slate v2 Exact Ledgers

Exact 1:1 legacy-file ledgers that complement the human control ledger in
release-file-review-ledger.md.

Rule:

• these ledgers are the archaeology layer

• they must stay exact per legacy file

• they do not dictate one-current-file-per-legacy-file recovery

• code proof should live in the smallest current behavior-domain owner file

• dead harness files should close as explicit-skip or mapped-mixed, not
  fake-recovered source cosplay

• legacy-slate-test-files.md

• legacy-slate-react-test-files.md

• legacy-slate-history-test-files.md

• legacy-playwright-example-tests.md

Status key:

• mapped-mirrored: current proof already carries the legacy file value
• mapped-recovered: current proof recovered the legacy file value on a new owner
• mapped-mixed: one legacy file splits into mirrored, recovered, and/or
  explicit-skip subclaims
• same-path-current: the same relative current test file still exists in slate-v2
• explicit-skip: intentionally outside the live contract
• needs-triage: no honest exact mapping exists yet

Overview (`docs/slate-v2/ledgers/README.md`) Copy Section

date: 2026-04-16 topic: slate-v2-ledgers-readme status: active Copy Chapter

Ledgers

Use this folder for package, API, test, and example inventories during the
fresh-branch migration.

Status words:

• recovered
• extended
• mixed
• open
• post RC
• cut

Current live ledgers:

• fork-issue-dossier.md
• example-parity-matrix.md
• legacy-playwright-example-tests.md
• legacy-slate-history-test-files.md
• legacy-slate-react-test-files.md
• legacy-slate-test-files.md
• slate-legacy-draft-contract-corpus.md
• slate-history-legacy-draft-contract-corpus.md
• slate-hyperscript-legacy-draft-contract-corpus.md
• slate-dom-legacy-draft-contract-corpus.md
• slate-react-legacy-draft-contract-corpus.md
• slate-editor-api.md
• slate-history-api.md
• slate-interfaces-api.md
• slate-react-api.md
• slate-transforms-api.md

Current tranche-3 owner docs:

• 2026-04-19-slate-absolute-api-replan.md
• fresh-branch-migration-plan.md

Current tranche-3 landed waves:

• 2026-04-18-slate-v2-slate-accessor-batch-wave-plan.md
• restored direct proof owners now live in .tmp/slate-v2:
  • packages/slate/test/query-contract.ts
  • packages/slate/test/legacy-editor-nodes-fixtures.ts
  • packages/slate/test/legacy-interfaces-fixtures.ts

Historical tranche-3 planning docs:

• the parity-first tranche docs below are historical context now
• 2026-04-18-slate-v2-slate-query-first-wave-plan.md
• 2026-04-18-slate-v2-slate-accessor-batch-wave-plan.md
• 2026-04-18-slate-v2-slate-interfaces-transforms-wave-plan.md

Overview (`docs/sync/shadcn/README.md`) Copy Section

Sync Shadcn

This directory tracks Plate's sync point against upstream shadcn-ui/ui
docs in ../shadcn/apps/v4.

• status.json records the current upstream commit baseline.
• decisions.md records durable keep/fork/exclude policy for Plate docs.
• runs/ stores range-specific audits, inventories, patches, and plans.

Use .agents/skills/sync-shadcn/SKILL.md before pulling newer upstream
shadcn docs changes into apps/www.

The baseline only moves after every upstream change in a range is accounted for
as adopted, smart-merged, intentionally forked, or explicitly excluded.

Overview (`packages/udecode/cmdk/README.md`) Copy Section

cmdk

Fork of cmdk with control actions.

• useCommandActions hook to control the command menu.

License Copy Chapter

MIT

Overview (`packages/udecode/cn/README.md`) Copy Section

`cn` utils

React & Tailwind utils used by Plate UI.

Documentation Copy Chapter

Visit https://platejs.org/docs/api/cn to view the documentation.

License Copy Chapter

MIT

Overview (`packages/udecode/depset/README.md`) Copy Section

depset

A command-line tool to synchronize package dependencies in your package.json to their latest versions, a specific target version, or versions matching a pattern.

Invocation Copy Chapter

Run depset using your preferred package manager:

• npx:
  bash Copy

  npx depset@latest [args...]

• pnpm:
  bash Copy

  pnpm dlx depset@latest [args...]

• yarn:
  bash Copy

  yarn dlx depset@latest [args...]

• bun:
  bash Copy

  bunx depset@latest [args...]

Usage Copy Chapter

depset [package-specifier] [target-version] [options]

Arguments Copy Chapter

• [package-specifier] (Optional)
  The package name or pattern to target. If omitted (and --yes is not used), you will be prompted.

  • Exact Name: e.g., lodash, @babel/core
  • Scope: e.g., @myorg (targets packages like @myorg/component-a, @myorg/utils)
  • Prefix: e.g., eslint-* (targets packages like eslint-plugin-react, eslint-config-next)

• [target-version] (Optional)
  The maximum version to synchronize to (e.g., "1", "1.2", "1.2.3"). If omitted (and neither --latest nor --yes are used), you will be prompted. If --latest is used, this is ignored.

Options Copy Chapter

Usage: depset [options] [package-specifier] [target-version]

Synchronize package dependencies to their latest or a specific version.

Arguments:
  package-specifier   Package name or pattern (e.g., "@scope/foo*", "my-package", "@myorg").
                      Prompts if not provided (unless -y is used).
  target-version      Target version (e.g., "1.2.3"). Prompts if not provided (unless -L or -y is used).
                      Defaults to latest if left blank in prompt or if -L is used.

Options:
  -L, --latest        Use the latest version, skip version prompt. (default: false)
  -i, --install       Automatically run install after updating package.json. (default: false)
  -y, --yes           Skip all confirmation prompts. (default: false)
  -c, --cwd     Set the current working directory. (default: current directory)
  -s, --silent        Silence all output except for errors. (default: false)
  -v, --version       Display the version number.
  -h, --help          Display help for command.

Examples Copy Chapter

1. Sync lodash to its latest version (prompts for version if not specified with --latest):

   bash Copy

   npx depset@latest lodash

2. Sync all packages in the @babel scope to their absolute latest versions, and install, skipping all prompts:

   bash Copy

   npx depset@latest @babel --latest --install --yes

3. Sync packages starting with eslint- up to version 8.50.0:

   bash Copy

   npx depset@latest "eslint-*" 8.50.0

   (You will be prompted to confirm changes and installation unless -y is used)

4. Run interactively, prompting for all inputs:

   bash Copy

   npx depset@latest

Overview (`packages/udecode/react-hotkeys/README.md`) Copy Section

Udecode react-hotkeys-hook fork

This is a fork of the original [email protected] and the following changes.

Documentation Copy Chapter

Visit https://platejs.org/docs/api/react-utils to view the documentation.

License Copy Chapter

MIT

Overview (`packages/udecode/react-utils/README.md`) Copy Section

Udecode React utils

React utils used by the many packages of the Udecode ecosystem.

Documentation Copy Chapter

Visit https://platejs.org/docs/api/react-utils to view the documentation.

License Copy Chapter

MIT

Overview (`packages/udecode/utils/README.md`) Copy Section

Udecode Utils

Utils used by the many packages of the Udecode ecosystem.

License Copy Chapter

MIT

Overview (`tooling/templates/plate-playground-template/README.md`) Copy Section

Playground Template

A Next.js template with Plate AI, plugins and components.

Features Copy Chapter

• Next.js 16
• Plate editor
• shadcn/ui
• MCP

Requirements Copy Chapter

• Node.js 20+
• bun

Installation Copy Chapter

Choose one of these methods:

1. Using CLI (Recommended) Copy Section

npx shadcn@latest add @plate/editor-ai

2. Using Template Copy Section

Use this template, then install dependencies:

bun install

Development Copy Chapter

Copy the example env file:

cp .env.example .env.local

Configure .env.local:

• UPLOADTHING_TOKEN – UploadThing API key (get one here)

Enter your own AI Gateway key in the editor settings to use AI. The example API routes use the caller's key.

Uploads work in local development. Before enabling production uploads, replace the development check in src/lib/uploadthing.ts with your application's session and permission checks. Add per-user upload limits.

If your application uses a shared server AI credential, authorize each request and enforce per-user usage limits before calling the provider. Keep server credentials out of client code.

Start the development server:

bun dev

Visit http://localhost:3000/editor to see the editor in action.

Overview (`docs/research/sources/editor-architecture/README.md`) Copy Section

Editor Architecture Sources

This directory holds compiled summaries for the editor-architecture comparison
lane.

Current scope:

• decorations / annotations / widget architecture
• React 19.2 perf architecture
• read/update lifecycle architecture across Lexical, ProseMirror, and Tiptap
• node/text/mark/render DX across ProseMirror, Lexical, and Tiptap

If future editor-architecture work moves into other surfaces, add separate
cluster pages instead of bloating a single mixed summary.

Current evidence is grounded in normalized raw families under ../raw, official
local repo clones under ../, plus the local plan docs that already captured
the Slate v2 decorations / annotations research.

Raw Corpus Availability Copy Chapter

As of 2026-04-23, the Lexical, ProseMirror, Tiptap, and Tiptap Docs raw source
families are normalized under ../raw.

Current raw evidence:

• ../raw/lexical/repo: official Lexical repo clone.
• ../raw/prosemirror/repo: official ProseMirror umbrella repo clone.
• ../raw/prosemirror/packages/*: official ProseMirror package clones for
  architecture evidence.
• ../raw/tiptap/repo: official Tiptap repo clone.
• ../raw/tiptap/docs: official Tiptap Docs repo clone.

Disposition:

• strongest evidence found: normalized official raw clones under ../raw
• raw gap: closed for the current read/update architecture pass
• compile gap: closed for read/update architecture; broader product areas such
  as tables, comments/suggestions, and AI tooling need separate passes if they
  become active

Current pages:

• decorations-annotations-overlay-corpus.md
• prosemirror-mapped-overlays-and-bookmarks.md
• lexical-mark-store-and-decorator-split.md
• react-19-2-external-store-and-background-ui.md
• tiptap-comments-suggestions-and-node-range.md
• slate-v2-local-proof-substrate.md
• layout-measurement-and-ime-lanes.md
• lightweight-editable-surface-lower-bound.md
• service-channels-and-live-stores.md
• read-update-runtime-corpus-ledger.md
• lexical-read-update-extension-runtime.md
• prosemirror-transaction-view-dom-runtime.md
• tiptap-extension-command-react-dx.md
• node-text-mark-render-dx-corpus-ledger.md
• scroll-selection-visibility-runtime.md
• pretext-pagination-page-virtualization.md

This directory should not turn into a dump of one-off notes.

Split it further only when the lane needs deeper per-corpus source pages.

Overview (`docs/research/sources/lexical/README.md`) Copy Section

Lexical Sources

This directory contains compiled research summaries derived from the official
Lexical monorepo at /Users/zbeyens/git/lexical plus the live docs entrypoints
on https://lexical.dev.

Current pages:

• markdown-package-and-shortcuts-doc-patterns.md

This layer is source-oriented. It is not yet the final decision layer.

Overview (`docs/research/sources/milkdown/README.md`) Copy Section

Milkdown Sources

This directory contains compiled research summaries derived from the upstream
Milkdown raw clone in ../raw/milkdown/repo and the raw entrypoint in
../raw/milkdown.

Current pages:

• corpus-overview.md
• editor-behavior-priority-map.md
• behavior-test-lanes.md
• docs-and-package-surface-map.md
• latex-trigger-surface.md
• input-autoformat-lanes.md

This layer is source-oriented. It is not yet the final concept/decision layer.

Overview (`docs/research/sources/obsidian/README.md`) Copy Section

Obsidian Sources

This directory contains compiled research summaries derived from:

• ../raw/obsidian/help
• ../raw/obsidian/developer

Current pages:

• corpus-overview.md
• editor-behavior-priority-map.md
• editing-modes-and-markdown-surface.md
• math-delimiters-and-pair-settings.md
• linking-navigation-and-search.md
• developer-editor-extension-surface.md
• footnotes-and-block-links.md

Overview (`docs/research/sources/prosemirror/README.md`) Copy Section

ProseMirror Sources

This directory contains compiled research summaries derived from the official
ProseMirror docs entrypoints on https://prosemirror.net plus the local repo at
/Users/zbeyens/git/prosemirror.

Current pages:

• guide-reference-and-example-doc-patterns.md

This layer is source-oriented. It is not yet the final decision layer.

Overview (`docs/research/sources/slate/README.md`) Copy Section

Slate Sources

This directory contains compiled research summaries derived from the official
Slate repo and docs at /Users/zbeyens/git/slate and https://docs.slatejs.org.

Current pages:

• walkthrough-concepts-and-api-doc-patterns.md

This layer is source-oriented. It is not yet the final decision layer.

Overview (`docs/research/sources/tiptap/README.md`) Copy Section

Tiptap Sources

This directory contains compiled research summaries derived from the normalized
Tiptap raw source family under ../raw/tiptap.

Raw entrypoints:

• docs: ../raw/tiptap/docs
• source/packages: ../raw/tiptap/repo
• catalog: ../raw/tiptap/catalog.md

Current pages:

• input-rules-and-extension-doc-patterns.md

This layer is source-oriented. It is not yet the final decision layer.

Overview (`docs/research/sources/typora/README.md`) Copy Section

Typora Sources

This directory will hold compiled summaries derived from ../raw/typora.

It should contain:

• summary pages for important Typora docs or release-note evidence
• compact behavior extracts
• links to impacted decision, concept, and system pages

Do not store raw captured Typora docs here.

Current pages:

• corpus-overview.md
• editor-behavior-priority-map.md
• markdown-native-editing-foundations.md
• clipboard-and-delete-behavior.md
• links-images-and-html-behavior.md
• media-authoring-and-path-policy.md
• navigation-search-outline-and-toc.md
• code-math-table-and-task-surfaces.md
• math-delimiter-triggers.md
• markdown-shorthand-and-inline-autoformat.md

One-to-one source-card material now lives in:

• ../raw/typora/page-cards/
• ../raw/typora/catalog.md

Overview (`templates/plate-playground-template/.agents/skills/react-useeffect/README.md`) Copy Section

React useEffect Best Practices

A comprehensive guide teaching when to use useEffect in React, and more importantly, when NOT to use it. This skill is based on official React documentation and provides practical alternatives to common useEffect anti-patterns.

Purpose Copy Chapter

Effects are an escape hatch from React's reactive paradigm. They let you synchronize with external systems like browser APIs, third-party widgets, or network requests. However, many developers overuse Effects for tasks that React handles better through other means.

This skill helps you:

• Identify when you truly need an Effect vs. when you don't
• Recognize common anti-patterns and their fixes
• Apply better alternatives like useMemo, key prop, and event handlers
• Write Effects that are clean, maintainable, and free from race conditions

When to Use This Skill Copy Chapter

Use this skill when you're:

• Writing or reviewing useEffect code
• Using useState to store derived values
• Implementing data fetching or subscriptions
• Synchronizing state between components
• Facing bugs with stale data or race conditions
• Wondering if your Effect is necessary

Trigger phrases:

• "Should I use useEffect for this?"
• "How do I fix this useEffect?"
• "My Effect is causing too many re-renders"
• "Data fetching with useEffect"
• "Reset state when props change"
• "Derived state from props"

How It Works Copy Chapter

This skill provides guidance through three key resources:

1. Quick Reference Table - Fast lookup for common scenarios with DO/DON'T patterns
2. Decision Tree - Visual flowchart to determine the right approach
3. Detailed Anti-Patterns - 9 common mistakes with explanations and fixes
4. Better Alternatives - 8 proven patterns to replace unnecessary Effects

The skill teaches you to ask the right questions:

• Is there an external system involved?
• Am I responding to a user event or component appearance?
• Can this value be calculated during render?
• Do I need to reset state when a prop changes?

Key Features Copy Chapter

1. Quick Reference Guide Copy Section

Visual table showing the DO/DON'T for common scenarios:

• Derived state from props/state
• Expensive calculations
• Resetting state on prop change
• User event responses
• Notifying parent components
• Data fetching

2. Decision Tree Copy Section

Clear flowchart that guides you from "Need to respond to something?" to the correct solution:

• User interaction → Event handler
• Component appeared → Effect (for external sync/analytics)
• Derived value needed → Calculate during render (+ useMemo if expensive)
• Reset state on prop change → Key prop

3. Anti-Pattern Recognition Copy Section

Detailed examples of 9 common mistakes:

1. Redundant state for derived values
2. Filtering/transforming data in Effect
3. Resetting state on prop change
4. Event-specific logic in Effect
5. Chains of Effects
6. Notifying parent via Effect
7. Passing data up to parent
8. Fetching without cleanup (race conditions)
9. App initialization in Effect

Each anti-pattern includes:

• Bad example with explanation
• Good example with fix
• Why the anti-pattern is problematic

4. Better Alternatives Copy Section

8 proven patterns to replace unnecessary Effects:

1. Calculate during render for derived state
2. useMemo for expensive calculations
3. key prop to reset state
4. Store ID instead of object for stable references
5. Event handlers for user actions
6. useSyncExternalStore for external stores
7. Lifting state up for shared state
8. Custom hooks for data fetching with cleanup

Usage Examples Copy Chapter

Example 1: Derived State Copy Section

Bad - Unnecessary Effect:

function Form() {
  const [firstName, setFirstName] = useState('Taylor');
  const [lastName, setLastName] = useState('Swift');
  const [fullName, setFullName] = useState('');

  useEffect(() => {
    setFullName(firstName + ' ' + lastName);
  }, [firstName, lastName]);
}

Good - Calculate during render:

function Form() {
  const [firstName, setFirstName] = useState('Taylor');
  const [lastName, setLastName] = useState('Swift');
  const fullName = firstName + ' ' + lastName; // Just compute it
}

Example 2: Resetting State Copy Section

Bad - Effect to reset:

function ProfilePage({ userId }) {
  const [comment, setComment] = useState('');

  useEffect(() => {
    setComment('');
  }, [userId]);
}

Good - Key prop:

function ProfilePage({ userId }) {
  return ;
}

function Profile({ userId }) {
  const [comment, setComment] = useState(''); // Resets automatically
}

Example 3: Data Fetching with Cleanup Copy Section

Bad - Race condition:

function SearchResults({ query }) {
  const [results, setResults] = useState([]);

  useEffect(() => {
    fetchResults(query).then(json => {
      setResults(json); // "hello" response may arrive after "hell"
    });
  }, [query]);
}

Good - Cleanup flag:

function SearchResults({ query }) {
  const [results, setResults] = useState([]);

  useEffect(() => {
    let ignore = false;

    fetchResults(query).then(json => {
      if (!ignore) setResults(json);
    });

    return () => { ignore = true; };
  }, [query]);
}

Example 4: Event Handler Instead of Effect Copy Section

Bad - Effect watching state:

function ProductPage({ product, addToCart }) {
  useEffect(() => {
    if (product.isInCart) {
      showNotification(`Added ${product.name}!`);
    }
  }, [product]);

  function handleBuyClick() {
    addToCart(product);
  }
}

Good - Handle in event:

function ProductPage({ product, addToCart }) {
  function handleBuyClick() {
    addToCart(product);
    showNotification(`Added ${product.name}!`);
  }
}

When You DO Need Effects Copy Chapter

Effects are appropriate for:

• Synchronizing with external systems - Browser APIs, third-party widgets, non-React code
• Subscriptions - WebSocket connections, global event listeners (prefer useSyncExternalStore)
• Analytics/logging - Code that needs to run because the component displayed
• Data fetching - With proper cleanup (or use your framework's built-in mechanism)

When You DON'T Need Effects Copy Chapter

Avoid Effects for:

1. Transforming data for rendering - Calculate at the top level instead
2. Handling user events - Use event handlers where you know exactly what happened
3. Deriving state - Just compute it: const fullName = firstName + ' ' + lastName
4. Chaining state updates - Calculate all next state in the event handler
5. Notifying parent components - Call the callback in the same event handler
6. Resetting state - Use the key prop to create a fresh component instance

Best Practices Copy Chapter

1. Start Without an Effect Copy Section

Before adding an Effect, ask: "Is there an external system involved?" If no, you probably don't need an Effect.

2. Prefer Derived State Copy Section

If you can calculate a value from props or state, don't store it in state with an Effect updating it.

3. Use the Right Tool Copy Section

• Expensive calculation → useMemo
• User interaction → Event handler
• Reset on prop change → key prop
• External subscription → useSyncExternalStore
• Shared state → Lift state up

4. Always Clean Up Copy Section

If your Effect subscribes, fetches, or sets timers, return a cleanup function to prevent memory leaks and race conditions.

5. Avoid Effect Chains Copy Section

Multiple Effects triggering each other causes unnecessary re-renders and makes code hard to follow. Calculate everything in one place (usually an event handler).

6. Test in Strict Mode Copy Section

React 18+ Strict Mode mounts components twice in development to expose missing cleanup. If your Effect breaks, you need cleanup.

7. Consider Framework Solutions Copy Section

For data fetching, prefer your framework's built-in solution (Next.js, Remix) or libraries (React Query, SWR) over manual Effects.

Reference Files Copy Chapter

This skill includes three detailed reference documents:

1. SKILL.md - Quick reference table and decision tree
2. anti-patterns.md - 9 common mistakes with detailed explanations
3. alternatives.md - 8 better alternatives with code examples

Common Pitfalls Copy Chapter

Multiple Re-renders Copy Section

Symptom: Component re-renders many times in quick succession.

Cause: Effect that sets state based on state it depends on, creating a loop.

Fix: Calculate the final value in an event handler or during render.

Stale Data Copy Section

Symptom: UI shows outdated values briefly before updating.

Cause: Using Effect to update derived state causes an extra render pass.

Fix: Calculate derived values during render instead of in state.

Race Conditions Copy Section

Symptom: Fast typing shows results for old queries after new ones.

Cause: Missing cleanup in data fetching Effect.

Fix: Use cleanup flag (ignore variable) or AbortController.

Runs Twice in Development Copy Section

Symptom: Effect runs twice on component mount in development.

Cause: React 18 Strict Mode intentionally mounts components twice to expose bugs.

Fix: Add proper cleanup. If it's app initialization that shouldn't run twice, use a module-level guard.

Resources Copy Chapter

This skill is based on:

• React Official Docs: You Might Not Need an Effect
• React Official Docs: Synchronizing with Effects
• React Official Docs: Lifecycle of Reactive Effects

Summary Copy Chapter

The golden rule: Effects are an escape hatch from React. If you're not synchronizing with an external system, you probably don't need an Effect.

Before writing useEffect, ask yourself:

1. Is this responding to a user interaction? → Use event handler
2. Is this a value I can calculate from props/state? → Calculate during render
3. Is this resetting state when a prop changes? → Use key prop
4. Is this synchronizing with an external system? → Use Effect with cleanup

Follow these patterns, and your React code will be more maintainable, performant, and bug-free.

Overview (`templates/plate-playground-template/.agents/skills/vercel-react-best-practices/README.md`) Copy Section

React Best Practices

A structured repository for creating and maintaining React Best Practices optimized for agents and LLMs.

Structure Copy Chapter

• rules/ - Individual rule files (one per rule)
  • _sections.md - Section metadata (titles, impacts, descriptions)
  • _template.md - Template for creating new rules
  • area-description.md - Individual rule files
• src/ - Build scripts and utilities
• metadata.json - Document metadata (version, organization, abstract)
• AGENTS.md - Compiled output (generated)
• test-cases.json - Test cases for LLM evaluation (generated)

Getting Started Copy Chapter

1. Install dependencies:

   bash Copy

   pnpm install

2. Build AGENTS.md from rules:

   bash Copy

   pnpm build

3. Validate rule files:

   bash Copy

   pnpm validate

4. Extract test cases:

   bash Copy

   pnpm extract-tests

Creating a New Rule Copy Chapter

1. Copy rules/_template.md to rules/area-description.md
2. Choose the appropriate area prefix:
   • async- for Eliminating Waterfalls (Section 1)
   • bundle- for Bundle Size Optimization (Section 2)
   • server- for Server-Side Performance (Section 3)
   • client- for Client-Side Data Fetching (Section 4)
   • rerender- for Re-render Optimization (Section 5)
   • rendering- for Rendering Performance (Section 6)
   • js- for JavaScript Performance (Section 7)
   • advanced- for Advanced Patterns (Section 8)
3. Fill in the frontmatter and content
4. Ensure you have clear examples with explanations
5. Run pnpm build to regenerate AGENTS.md and test-cases.json

Rule File Structure Copy Chapter

Each rule file should follow this structure:

---
title: Rule Title Here
impact: MEDIUM
impactDescription: Optional description
tags: tag1, tag2, tag3
---

## Rule Title Here

Brief explanation of the rule and why it matters.

**Incorrect (description of what's wrong):**

```typescript
// Bad code example

Correct (description of what's right):

// Good code example

Optional explanatory text after examples.

Reference: Link

File Naming Convention Copy Chapter

• Files starting with _ are special (excluded from build)
• Rule files: area-description.md (e.g., async-parallel.md)
• Section is automatically inferred from filename prefix
• Rules are sorted alphabetically by title within each section
• IDs (e.g., 1.1, 1.2) are auto-generated during build

Impact Levels Copy Chapter

• CRITICAL - Highest priority, major performance gains
• HIGH - Significant performance improvements
• MEDIUM-HIGH - Moderate-high gains
• MEDIUM - Moderate performance improvements
• LOW-MEDIUM - Low-medium gains
• LOW - Incremental improvements

Scripts Copy Chapter

• pnpm build - Compile rules into AGENTS.md
• pnpm validate - Validate all rule files
• pnpm extract-tests - Extract test cases for LLM evaluation
• pnpm dev - Build and validate

Contributing Copy Chapter

When adding or modifying rules:

1. Use the correct filename prefix for your section
2. Follow the _template.md structure
3. Include clear bad/good examples with explanations
4. Add appropriate tags
5. Run pnpm build to regenerate AGENTS.md and test-cases.json
6. Rules are automatically sorted by title - no need to manage numbers!

Acknowledgments Copy Chapter

Originally created by @shuding at Vercel.

Overview (`templates/plate-template/.agents/skills/react-useeffect/README.md`) Copy Section

React useEffect Best Practices

A comprehensive guide teaching when to use useEffect in React, and more importantly, when NOT to use it. This skill is based on official React documentation and provides practical alternatives to common useEffect anti-patterns.

Purpose Copy Chapter

Effects are an escape hatch from React's reactive paradigm. They let you synchronize with external systems like browser APIs, third-party widgets, or network requests. However, many developers overuse Effects for tasks that React handles better through other means.

This skill helps you:

• Identify when you truly need an Effect vs. when you don't
• Recognize common anti-patterns and their fixes
• Apply better alternatives like useMemo, key prop, and event handlers
• Write Effects that are clean, maintainable, and free from race conditions

When to Use This Skill Copy Chapter

Use this skill when you're:

• Writing or reviewing useEffect code
• Using useState to store derived values
• Implementing data fetching or subscriptions
• Synchronizing state between components
• Facing bugs with stale data or race conditions
• Wondering if your Effect is necessary

Trigger phrases:

• "Should I use useEffect for this?"
• "How do I fix this useEffect?"
• "My Effect is causing too many re-renders"
• "Data fetching with useEffect"
• "Reset state when props change"
• "Derived state from props"

How It Works Copy Chapter

This skill provides guidance through three key resources:

1. Quick Reference Table - Fast lookup for common scenarios with DO/DON'T patterns
2. Decision Tree - Visual flowchart to determine the right approach
3. Detailed Anti-Patterns - 9 common mistakes with explanations and fixes
4. Better Alternatives - 8 proven patterns to replace unnecessary Effects

The skill teaches you to ask the right questions:

• Is there an external system involved?
• Am I responding to a user event or component appearance?
• Can this value be calculated during render?
• Do I need to reset state when a prop changes?

Key Features Copy Chapter

1. Quick Reference Guide Copy Section

Visual table showing the DO/DON'T for common scenarios:

• Derived state from props/state
• Expensive calculations
• Resetting state on prop change
• User event responses
• Notifying parent components
• Data fetching

2. Decision Tree Copy Section

Clear flowchart that guides you from "Need to respond to something?" to the correct solution:

• User interaction → Event handler
• Component appeared → Effect (for external sync/analytics)
• Derived value needed → Calculate during render (+ useMemo if expensive)
• Reset state on prop change → Key prop

3. Anti-Pattern Recognition Copy Section

Detailed examples of 9 common mistakes:

1. Redundant state for derived values
2. Filtering/transforming data in Effect
3. Resetting state on prop change
4. Event-specific logic in Effect
5. Chains of Effects
6. Notifying parent via Effect
7. Passing data up to parent
8. Fetching without cleanup (race conditions)
9. App initialization in Effect

Each anti-pattern includes:

• Bad example with explanation
• Good example with fix
• Why the anti-pattern is problematic

4. Better Alternatives Copy Section

8 proven patterns to replace unnecessary Effects:

1. Calculate during render for derived state
2. useMemo for expensive calculations
3. key prop to reset state
4. Store ID instead of object for stable references
5. Event handlers for user actions
6. useSyncExternalStore for external stores
7. Lifting state up for shared state
8. Custom hooks for data fetching with cleanup

Usage Examples Copy Chapter

Example 1: Derived State Copy Section

Bad - Unnecessary Effect:

function Form() {
  const [firstName, setFirstName] = useState('Taylor');
  const [lastName, setLastName] = useState('Swift');
  const [fullName, setFullName] = useState('');

  useEffect(() => {
    setFullName(firstName + ' ' + lastName);
  }, [firstName, lastName]);
}

Good - Calculate during render:

function Form() {
  const [firstName, setFirstName] = useState('Taylor');
  const [lastName, setLastName] = useState('Swift');
  const fullName = firstName + ' ' + lastName; // Just compute it
}

Example 2: Resetting State Copy Section

Bad - Effect to reset:

function ProfilePage({ userId }) {
  const [comment, setComment] = useState('');

  useEffect(() => {
    setComment('');
  }, [userId]);
}

Good - Key prop:

function ProfilePage({ userId }) {
  return <Profile userId={userId} key={userId} />;
}

function Profile({ userId }) {
  const [comment, setComment] = useState(''); // Resets automatically
}

Example 3: Data Fetching with Cleanup Copy Section

Bad - Race condition:

function SearchResults({ query }) {
  const [results, setResults] = useState([]);

  useEffect(() => {
    fetchResults(query).then(json => {
      setResults(json); // "hello" response may arrive after "hell"
    });
  }, [query]);
}

Good - Cleanup flag:

function SearchResults({ query }) {
  const [results, setResults] = useState([]);

  useEffect(() => {
    let ignore = false;

    fetchResults(query).then(json => {
      if (!ignore) setResults(json);
    });

    return () => { ignore = true; };
  }, [query]);
}

Example 4: Event Handler Instead of Effect Copy Section

Bad - Effect watching state:

function ProductPage({ product, addToCart }) {
  useEffect(() => {
    if (product.isInCart) {
      showNotification(`Added ${product.name}!`);
    }
  }, [product]);

  function handleBuyClick() {
    addToCart(product);
  }
}

Good - Handle in event:

function ProductPage({ product, addToCart }) {
  function handleBuyClick() {
    addToCart(product);
    showNotification(`Added ${product.name}!`);
  }
}

When You DO Need Effects Copy Chapter

Effects are appropriate for:

• Synchronizing with external systems - Browser APIs, third-party widgets, non-React code
• Subscriptions - WebSocket connections, global event listeners (prefer useSyncExternalStore)
• Analytics/logging - Code that needs to run because the component displayed
• Data fetching - With proper cleanup (or use your framework's built-in mechanism)

When You DON'T Need Effects Copy Chapter

Avoid Effects for:

1. Transforming data for rendering - Calculate at the top level instead
2. Handling user events - Use event handlers where you know exactly what happened
3. Deriving state - Just compute it: const fullName = firstName + ' ' + lastName
4. Chaining state updates - Calculate all next state in the event handler
5. Notifying parent components - Call the callback in the same event handler
6. Resetting state - Use the key prop to create a fresh component instance

Best Practices Copy Chapter

1. Start Without an Effect Copy Section

Before adding an Effect, ask: "Is there an external system involved?" If no, you probably don't need an Effect.

2. Prefer Derived State Copy Section

If you can calculate a value from props or state, don't store it in state with an Effect updating it.

3. Use the Right Tool Copy Section

• Expensive calculation → useMemo
• User interaction → Event handler
• Reset on prop change → key prop
• External subscription → useSyncExternalStore
• Shared state → Lift state up

4. Always Clean Up Copy Section

If your Effect subscribes, fetches, or sets timers, return a cleanup function to prevent memory leaks and race conditions.

5. Avoid Effect Chains Copy Section

Multiple Effects triggering each other causes unnecessary re-renders and makes code hard to follow. Calculate everything in one place (usually an event handler).

6. Test in Strict Mode Copy Section

React 18+ Strict Mode mounts components twice in development to expose missing cleanup. If your Effect breaks, you need cleanup.

7. Consider Framework Solutions Copy Section

For data fetching, prefer your framework's built-in solution (Next.js, Remix) or libraries (React Query, SWR) over manual Effects.

Reference Files Copy Chapter

This skill includes three detailed reference documents:

1. SKILL.md - Quick reference table and decision tree
2. anti-patterns.md - 9 common mistakes with detailed explanations
3. alternatives.md - 8 better alternatives with code examples

Common Pitfalls Copy Chapter

Multiple Re-renders Copy Section

Symptom: Component re-renders many times in quick succession.

Cause: Effect that sets state based on state it depends on, creating a loop.

Fix: Calculate the final value in an event handler or during render.

Stale Data Copy Section

Symptom: UI shows outdated values briefly before updating.

Cause: Using Effect to update derived state causes an extra render pass.

Fix: Calculate derived values during render instead of in state.

Race Conditions Copy Section

Symptom: Fast typing shows results for old queries after new ones.

Cause: Missing cleanup in data fetching Effect.

Fix: Use cleanup flag (ignore variable) or AbortController.

Runs Twice in Development Copy Section

Symptom: Effect runs twice on component mount in development.

Cause: React 18 Strict Mode intentionally mounts components twice to expose bugs.

Fix: Add proper cleanup. If it's app initialization that shouldn't run twice, use a module-level guard.

Resources Copy Chapter

This skill is based on:

• React Official Docs: You Might Not Need an Effect
• React Official Docs: Synchronizing with Effects
• React Official Docs: Lifecycle of Reactive Effects

Summary Copy Chapter

The golden rule: Effects are an escape hatch from React. If you're not synchronizing with an external system, you probably don't need an Effect.

Before writing useEffect, ask yourself:

1. Is this responding to a user interaction? → Use event handler
2. Is this a value I can calculate from props/state? → Calculate during render
3. Is this resetting state when a prop changes? → Use key prop
4. Is this synchronizing with an external system? → Use Effect with cleanup

Follow these patterns, and your React code will be more maintainable, performant, and bug-free.

Overview (`templates/plate-template/.agents/skills/vercel-react-best-practices/README.md`) Copy Section

React Best Practices

A structured repository for creating and maintaining React Best Practices optimized for agents and LLMs.

Structure Copy Chapter

• rules/ - Individual rule files (one per rule)
  • _sections.md - Section metadata (titles, impacts, descriptions)
  • _template.md - Template for creating new rules
  • area-description.md - Individual rule files
• src/ - Build scripts and utilities
• metadata.json - Document metadata (version, organization, abstract)
• AGENTS.md - Compiled output (generated)
• test-cases.json - Test cases for LLM evaluation (generated)

Getting Started Copy Chapter

1. Install dependencies:

   bash Copy

   pnpm install

2. Build AGENTS.md from rules:

   bash Copy

   pnpm build

3. Validate rule files:

   bash Copy

   pnpm validate

4. Extract test cases:

   bash Copy

   pnpm extract-tests

Creating a New Rule Copy Chapter

1. Copy rules/_template.md to rules/area-description.md
2. Choose the appropriate area prefix:
   • async- for Eliminating Waterfalls (Section 1)
   • bundle- for Bundle Size Optimization (Section 2)
   • server- for Server-Side Performance (Section 3)
   • client- for Client-Side Data Fetching (Section 4)
   • rerender- for Re-render Optimization (Section 5)
   • rendering- for Rendering Performance (Section 6)
   • js- for JavaScript Performance (Section 7)
   • advanced- for Advanced Patterns (Section 8)
3. Fill in the frontmatter and content
4. Ensure you have clear examples with explanations
5. Run pnpm build to regenerate AGENTS.md and test-cases.json

Rule File Structure Copy Chapter

Each rule file should follow this structure:

---
title: Rule Title Here
impact: MEDIUM
impactDescription: Optional description
tags: tag1, tag2, tag3
---

## Rule Title Here

Brief explanation of the rule and why it matters.

**Incorrect (description of what's wrong):**

```typescript
// Bad code example

Correct (description of what's right):

// Good code example

Optional explanatory text after examples.

Reference: Link

File Naming Convention Copy Chapter

• Files starting with _ are special (excluded from build)
• Rule files: area-description.md (e.g., async-parallel.md)
• Section is automatically inferred from filename prefix
• Rules are sorted alphabetically by title within each section
• IDs (e.g., 1.1, 1.2) are auto-generated during build

Impact Levels Copy Chapter

• CRITICAL - Highest priority, major performance gains
• HIGH - Significant performance improvements
• MEDIUM-HIGH - Moderate-high gains
• MEDIUM - Moderate performance improvements
• LOW-MEDIUM - Low-medium gains
• LOW - Incremental improvements

Scripts Copy Chapter

• pnpm build - Compile rules into AGENTS.md
• pnpm validate - Validate all rule files
• pnpm extract-tests - Extract test cases for LLM evaluation
• pnpm dev - Build and validate

Contributing Copy Chapter

When adding or modifying rules:

1. Use the correct filename prefix for your section
2. Follow the _template.md structure
3. Include clear bad/good examples with explanations
4. Add appropriate tags
5. Run pnpm build to regenerate AGENTS.md and test-cases.json
6. Rules are automatically sorted by title - no need to manage numbers!

Acknowledgments Copy Chapter

Originally created by @shuding at Vercel.

Overview (`apps/www/src/__tests__/package-integration/__deferred__/README.md`) Copy Section

Deferred Integration Red Suite

This folder is for future-contract integration tests that are intentionally red.

Use it when:

• the protocol doc names an interaction class we still do not implement
• the expected future behavior is clear enough to write down now
• mixing the red spec into the normal green suite would be stupid

Do not use it for:

• vague ideas
• duplicate green tests
• package-local unit seams

Rules:

• keep specs under domain folders like clipboard, ime, mouse-selection,
  and platform-shortcuts
• use *.deferred.spec.ts[x]
• reference the future protocol lane or spec ID in the title or file
• keep the assertions public-interface focused
• do not import app-registry fluff if a smaller seam exists

Normal pnpm test and pnpm test:slow ignore this folder.

Run it explicitly with:

pnpm test:deferred

That command expects the suite to stay red. If everything suddenly passes, the
runner fails so the specs get promoted instead of rotting here.

Overview (`apps/www/src/registry/changelog/entries/README.md`) Copy Section

Registry changelog entries

This directory is the source for Plate UI registry changelog entries.

One file equals one changelog event. Generated public JSON lives one directory
up in apps/www/src/registry/changelog/*.json; do not edit that JSON by hand.

Create an Entry Copy Chapter

node tooling/scripts/generate-ui-changelog-entries.mjs \
  --new 2026-06-15-fix-editor-wrapping \
  --summary "Fix editor wrapping" \
  --items editor,editor-static \
  --kind fix

Then regenerate and verify:

node tooling/scripts/generate-ui-changelog-entries.mjs --write
node tooling/scripts/generate-ui-changelog-entries.mjs --check

Shape Copy Chapter

---
id: 2026-06-15-fix-editor-wrapping
date: 2026-06-15
status: draft
kind: fix
summary: "Fix editor wrapping"
change: {"type":"source","date":"2026-06-15","commits":[]}
release: {"status":"unresolved"}
diagnostics: []
---

- **`editor`**, **`editor-static`**: Fix preserved-space wrapping in editable and static editors.

Keep prose user-facing. Do not include implementation notes, test notes, or
internal architecture rationale.

Docs Index (`content/docs/index.mdx`) Copy Section

title: Introduction Copy Chapter

Plate is a React framework for building rich-text editors. It gives you a headless editor runtime, composable plugins, and optional Plate UI components that you copy into your app. Start with Plate UI for a complete editor, or use the packages directly when you need a headless setup.

Choose a Path Copy Chapter

What Plate Owns Copy Chapter

Why Plate UI? Copy Chapter

Plate UI follows the shadcn/ui model: you copy the code, own it, and keep editing it in your app.

• Open code: The UI layer is app-local code, not a sealed component package.
• Composition: Components use predictable React and shadcn/ui conventions.
• CLI distribution: Add kits, templates, components, API routes, and docs through the shadcn CLI.
• AI-ready: Open component code and consistent registry metadata give agents real context.
• MCP-ready: The MCP setup lets AI tools inspect and apply Plate registry items.

Done. You can install the full UI path, drop down to headless packages, or start from an editor template.

FAQ Copy Chapter

Credits Copy Chapter

• shadcn/ui - For UI inspiration, documentation, and the CLI.
• Radix UI - For the unstyled, accessible primitives.
• Vercel - For hosting.
• Shu Ding - Typography style adapted from Nextra.
• cmdk - For the <Command /> component.

Research Index (`docs/research/index.md`) Copy Section

Research Index

This is the entrypoint for the compiled agent research layer.

Top Level Copy Chapter

• README.md
  Source of truth for the research pattern, operating rules, and layer boundaries.
• log.md
  Append-only operational history for research ingests and restructures.
• schema.md
  Minimal metadata contract for the research page types.

Directories Copy Chapter

• commands/README.md
  Operational command specs for running the research workflows.
• sources/README.md
  Compiled summaries of raw evidence.
• decisions/README.md
  Canonical repo-relevant choices and policy calls.
• concepts/README.md
  Shared vocabulary and abstractions.
• systems/README.md
  Architecture and authority maps.
• editor-behavior-architecture.md
  Long-horizon architecture for profile-driven editor behavior.
• systems/editor-architecture-landscape.md
  Compiled comparison map for the editor architecture candidate lane behind the
  Slate v2 overlay rewrite.
• systems/slate-v2-overlay-architecture.md
  Stable research-layer architecture map for the Slate v2 overlay system.
• entities/README.md
  Concrete named things like editors, packages, and plugins.
• entities/typora.md
  Seed entity page for the first editor-reference corpus.
• open-questions/README.md
  Known ambiguity that should not be flattened into fake certainty.

First Targets Copy Chapter

• operational baseline:
  commands/full-pipeline.md
• upkeep baseline:
  commands/maintain.md
• Typora compiled source pages derived from ../raw/typora, starting in
  sources/typora/README.md
• first compiled Typora source pages:
  corpus-overview.md
  and
  editor-behavior-priority-map.md
• first Typora source-cluster syntheses:
  markdown-native-editing-foundations.md,
  clipboard-and-delete-behavior.md,
  links-images-and-html-behavior.md,
  media-authoring-and-path-policy.md,
  navigation-search-outline-and-toc.md,
  and
  code-math-table-and-task-surfaces.md
  plus
  math-delimiter-triggers.md
  plus
  markdown-shorthand-and-inline-autoformat.md
• Typora system map:
  typora-behavior-map.md
• first Typora-derived concepts and decisions now exist under:
  concepts/,
  decisions/,
  and
  open-questions/
• newer date/media expansion follow-up now also includes:
  • media-authoring-follows-the-image-path-policy-family.md
  • date-mdx-payload-contract.md
  • math-delimiter-trigger-authority.md
• editor architecture lane now also includes:
  • sources/editor-architecture/README.md
  • decorations-annotations-overlay-corpus.md
  • narrower source clusters for:
    ProseMirror,
    Lexical,
    Tiptap,
    local Slate v2 proof,
    layout/measurement/IME,
    lightweight editable surfaces,
    and service/store models
  • systems/editor-architecture-landscape.md
  • systems/slate-v2-perfect-plan-steal-reject-defer-map.md
  • systems/slate-v2-overlay-architecture.md
  • slate-v2-overlay-architecture-cuts.md
  • slate-v2-overlay-superiority-vs-legacy-and-field.md
  • react-19-2-external-store-and-background-ui.md
  • tanstack-virtual-and-github-large-surface-virtualization.md
  • pretext-pagination-page-virtualization.md
  • slate-v2-react-19-2-perf-architecture-vs-field.md
  • source-scoped-overlay-invalidation.md
  • slate-v2-source-scoped-overlay-invalidation.md
  • slate-v2-collaborative-annotation-channels.md
  • slate-v2-data-model-first-react-perfect-runtime.md
  • read-update-runtime-corpus-ledger.md
  • lexical-read-update-extension-runtime.md
  • prosemirror-transaction-view-dom-runtime.md
  • tiptap-extension-command-react-dx.md
  • slate-v2-read-update-runtime-architecture.md
  • slate-v2-perfect-plan-should-steal-read-update-transaction-discipline-and-extension-dx.md
  • slate-v2-state-tx-public-api-and-extension-namespaces.md
  • slate-v2-post-closure-architecture-review.md
  • slate-v2-architecture-verdict-after-human-stress-sweep.md
  • node-text-mark-render-dx-corpus-ledger.md
  • scroll-selection-visibility-runtime.md
  • editor-node-text-mark-dx-landscape.md
  • editor-node-dx-should-use-runtime-owned-shells-and-spec-first-renderers.md
  • concept pages for:
    overlay-lane-separation,
    durable-anchor-vs-live-handle,
    runtime-identity-vs-tree-address,
    and
    source-scoped-overlay-invalidation
  • entity pages for:
    ProseMirror,
    Lexical,
    Tiptap,
    Premirror,
    Pretext,
    Slate,
    edix,
    use-editable,
    rich-textarea,
    VS Code,
    TanStack DB,
    and
    EditContext
• Milkdown compiled source pages derived from ../raw/milkdown, starting in
  sources/milkdown/README.md
• Obsidian compiled source pages derived from ../raw/obsidian, starting in
  sources/obsidian/README.md
• Obsidian now also has:
  • footnotes-and-block-links.md
  • math-delimiters-and-pair-settings.md
  • obsidian-authority-scope.md
• Milkdown now also has:
  • latex-trigger-surface.md
  • input-autoformat-lanes.md
• autoformat follow-up now also includes:
  • autoformat-families-are-profile-adjacent-input-assist-surfaces.md
  • link-automd-belongs-to-the-link-interaction-lane.md
  • current-kit-autoformat-normalization-split.md
  • text-substitution-autoformat-authority.md
• input-rule docs IA follow-up now also includes:
  • sources/tiptap/input-rules-and-extension-doc-patterns.md
  • sources/prosemirror/guide-reference-and-example-doc-patterns.md
  • sources/lexical/markdown-package-and-shortcuts-doc-patterns.md
  • sources/slate/walkthrough-concepts-and-api-doc-patterns.md
  • systems/plugin-input-rule-doc-pattern-landscape.md
  • decisions/plugin-input-rules-guide-should-lead-with-runtime-first-then-feature-owners-then-api-reference.md
• one-to-one Typora source-card layer now lives in:
  ../raw/typora/page-cards/ and ../raw/typora/catalog.md
• cross-links from Typora pages into existing
  docs/editor-behavior
  source-of-truth docs

Slate Browser Overview (`docs/slate-browser/overview.md`) Copy Section

date: 2026-04-03 topic: slate-browser-testing-framework-overview Copy Chapter

Slate Browser Testing Framework Overview

Specialist testing/proof doc. For current queue and roadmap truth, see master-roadmap.md.

Purpose Copy Chapter

This doc defines the specialist testing/proof lane for editor work and the
future testing-framework direction it draws from
editor-architecture-candidates.md.

This is not a “pick one runner and call it done” doc.

Strong take:

• the best editor testing framework is layered
• one runner to rule them all is a trap
• speed, fidelity, and coverage want different tools

slate-browser is a good name for this doc area because the main unsolved gap
is browser-facing editor behavior, not pure core semantics. This repo keeps
internal docs under docs/, so the doc lives in docs/slate-browser/.

Follow-up docs:

• framework-design.md
• api-design.md
• proof-lane-matrix.md
• next-api-candidates.md
• next-api-candidates-matrix.md
• four-way-api-deep-dive.md
• next-system-move.md
• prioritized-backlog.md

Current package:

• package:
  /Users/zbeyens/git/slate-v2/packages/slate-browser
• Playwright harness entrypoint:
  /Users/zbeyens/git/slate-v2/packages/slate-browser/src/playwright/index.ts

Canonical root commands:

• yarn build:slate-browser:playwright
• yarn setup:slate-browser
• yarn test:slate-browser
• yarn test:slate-browser:core
• yarn test:slate-browser:dom
• yarn test:slate-browser:selection
• yarn test:slate-browser:e2e
• yarn test:slate-browser:e2e:local
• yarn test:slate-browser:ime
• yarn test:slate-browser:ime:local
• yarn test:slate-browser:anchors
• yarn test:replacement:compat:local
• yarn test:replacement:gate:local

Current role:

• slate-browser is the specialist testing/proof lane for the master roadmap
• it does not own roadmap truth or queue order
• it feeds the emitted-artifact obligations in
  true-slate-rc-proof-ledger.md
• the current live browser/runtime proof rows are carried by:
  • runtime.tsx
  • replacement-compatibility.test.ts
• if slate-browser work reopens, the current follow-on seam is captured in
  next-system-move.md

Migration Review Rule Copy Chapter

When a browser lane disappears or changes shape, the acceptance bar is not
"there used to be a file with that name."

The acceptance bar is:

• the contributor-facing concept still exists
• the proof owner is explicit in
  proof-lane-matrix.md
  or the live docs/slate-v2 verdict docs
• the moved or removed lane is documented in the maintainer diff story

What We Are Optimizing For Copy Chapter

1. fast local feedback
2. real browser behavior when browser behavior is the thing under test
3. first-class IME/composition coverage
4. deterministic selection assertions
5. performance lanes that measure instead of hand-wave
6. future agent-native extensibility, so an agent layer can be added later
   without distorting the deterministic core design

Best Ideas By Repo Copy Chapter

Lexical Copy Chapter

Best steal:

• real browser IME tests with Chromium CDP
• selection assertions as first-class artifacts
• explicit browser matrix for e2e

Key files:

• /Users/zbeyens/git/lexical/packages/lexical-playground/tests/e2e/Composition.spec.mjs
• /Users/zbeyens/git/lexical/packages/lexical-playground/tests/utils/index.mjs

Take:

• this is the best model for the IME lane
• do not try to reinvent IME testing in jsdom when Lexical already proved the
  right browser seam

Slate Copy Chapter

Best steal:

• example-driven Playwright integration already exists
• mixed unit/dom/browser stack already covers real product surfaces

Key files:

• /Users/zbeyens/git/slate-v2/playwright/integration/examples/placeholder.test.ts
• /Users/zbeyens/git/slate-v2/package.json

Take:

• keep Slate’s Playwright harness
• grow it instead of replacing it

edix Copy Chapter

Best steal:

• Vitest project split between fast unit and browser tests
• Playwright e2e plus direct IME cases in the same repo

Key files:

• /Users/zbeyens/git/edix/vitest.config.ts
• /Users/zbeyens/git/edix/e2e/common.spec.ts

Take:

• this is the best small-repo shape for “fast browser contract tests”
• especially useful for focused DOM/selection assertions that are too browser-ish
  for jsdom but too small for heavyweight e2e suites

rich-textarea Copy Chapter

Best steal:

• composition-aware selection compensation
• split between unit, browser-story, and Playwright e2e

Key files:

• /Users/zbeyens/git/rich-textarea/src/selection.ts
• /Users/zbeyens/git/rich-textarea/vitest.config.ts
• /Users/zbeyens/git/rich-textarea/e2e/textarea.spec.ts

Take:

• good model for lightweight surfaces and composition-aware selection helpers
• not enough on its own for rich-contenteditable editor coverage

Tiptap Copy Chapter

Best steal:

• good placeholder extension tests
• decent product-DX test posture with unit + Cypress

Key files:

• /Users/zbeyens/git/tiptap/packages/extensions/tests/placeholder.spec.ts
• /Users/zbeyens/git/tiptap/package.json

Take:

• useful for extension behavior and product-layer regression shape
• not the best IME or low-level browser harness model

Premirror Copy Chapter

Best steal:

• the cleanest written testing strategy for layout, determinism, and perf

Key file:

• /Users/zbeyens/git/premirror/docs/testing-strategy.md

Take:

• best source for test-lane taxonomy and perf-governance language
• especially useful once editor testing expands into composition/layout/perf

Pretext Copy Chapter

Best steal:

• accuracy and benchmark checks as first-class scripts

Key file:

• /Users/zbeyens/git/pretext/package.json

Take:

• useful for measurement/perf verification design
• not a general editor-testing framework model

VS Code Copy Chapter

Best steal:

• layered test entrypoints:
  node, browser, extension, smoke, perf

Key file:

• /Users/zbeyens/git/vscode/package.json

Take:

• strongest structure for “many lanes, explicit commands, no one-suite delusion”

ProseMirror Copy Chapter

Best steal:

• almost nothing framework-specific here for our testing problem beyond
  disciplined core tests

Key file:

• /Users/zbeyens/git/prosemirror/package.json

Take:

• good engine influence
• weak direct testing-framework influence for this problem

use-editable and markdown-editor Copy Chapter

Best steal:

• no strong testing-framework leverage for this problem

Key files:

• /Users/zbeyens/git/use-editable/package.json
• /Users/zbeyens/git/markdown-editor/package.json

Take:

• useful product/code references
• not testing-framework references

urql and TanStack DB Copy Chapter

Best steal:

• project-split Vitest discipline
• explicit e2e subpackages

Key files:

• /Users/zbeyens/git/urql/package.json
• /Users/zbeyens/git/db/package.json

Take:

• useful for repo-wide test-lane organization
• not editor-specific behavior coverage

Agent-Browser / Dev-Browser / OMX Copy Chapter

Best steal:

• agent-native lane for actions Playwright does poorly or too rigidly
• explicit capability-coverage thinking

Key files:

• /Users/zbeyens/git/agent-browser/AGENTS.md
• /Users/zbeyens/git/dev-browser/package.json
• /Users/zbeyens/git/oh-my-codex/COVERAGE.md

Take:

• agent-native testing should be designed in as a future extension seam
• but it should not shape the first deterministic framework layers

Recommended Framework Shape Copy Chapter

This is a layered base with a few specialized lanes on top of it.

• Layers are about dependency order.
• Lanes are about specialized risk classes.

Layer 0: Core Fast Tests Copy Chapter

Purpose:

• pure model, transform, selection, and projection semantics

Tools:

• fast package-local runner
• current Slate mix is acceptable short-term
• longer-term, Vitest-style project splits are cleaner than Mocha/Jest drift

Steal from:

• Slate v2 proof packages
• edix Vitest split
• TanStack DB / urql test organization

Layer 1: DOM Contract Tests Copy Chapter

Purpose:

• DOM translation, selection math, placeholder shape, clipboard DOM adaptation
• focused browser-backed contracts for one seam at a time
• no example-app orchestration

Tools:

• fast browser-backed contract tests, not only jsdom
• best future direction: Vitest browser + Playwright provider for small contract
  lanes

Steal from:

• edix vitest.config.ts
• rich-textarea vitest.config.ts

Layer 2: Example Integration Tests Copy Chapter

Purpose:

• assert real editor behavior on real app/example surfaces
• cross-feature flows and product-shaped regressions
• use when the behavior only makes sense once the full example is mounted

Tools:

• Playwright

Steal from:

• Slate existing Playwright example tests
• VS Code multi-entry lane organization

Lane A: IME / Composition Copy Chapter

Purpose:

• empty-state composition
• placeholder-sensitive composition
• range/selection after commit
• browser-ordering quirks

Tools:

• Chromium Playwright + CDP for first lane
• later WebKit/Safari regression lanes where needed

Steal from:

• Lexical IME e2e tests
• edix IME e2e tests

Strong take:

• this lane must exist
• jsdom composition is not enough

Lane B: Agent-Native Copy Chapter

Purpose:

• cover actions that humans can do but deterministic browser scripts either
  express badly or not at all

Examples:

• weird selection drags
• multi-step context-menu workflows
• visual proofreading of cursor/toolbar state
• copy/paste flows where OS/browser glue matters

Tools:

• dev-browser
• agent-browser

Rules:

• every agent-native test still needs explicit assertions or artifacts
• screenshots, DOM dumps, selection dumps, and event logs must be captured
• this lane complements deterministic suites; it does not replace them

Lane C: Performance Copy Chapter

Purpose:

• benchmark real editor behaviors without mixing them into correctness suites

Steal from:

• Premirror testing strategy
• Pretext benchmark/accuracy scripts
• VS Code explicit perf command separation

Agent-Native Review Copy Chapter

Using the agent-native-reviewer lens, the future framework should require:

1. Every critical user action has at least one deterministic test lane.
2. Every action Playwright cannot faithfully express has an agent-native lane.
3. Agent-native runs operate in the same workspace and examples as human tests.
4. Capabilities are explicit, not tribal knowledge.

Current gap:

• Slate has Playwright example tests, but no first-class documented
  agent-native lane for editor actions

That is a real framework gap.

Recommended Stack Copy Chapter

Do not chase a single universal runner.

Best stack is:

• fast local/unit layer:
  current package runners, converging toward Vitest-style project splits
• browser contract layer:
  Vitest browser + Playwright provider
• integration/e2e layer:
  Playwright
• IME layer:
  Playwright + Chromium CDP composition helpers
• perf layer:
  explicit benchmark scripts
• agent-native layer:
  dev-browser / agent-browser

Adoption Order Copy Chapter

1. Keep the current public package/API tranche stable.
2. Strengthen openExample(...) into a real readiness contract.
3. Build the renderer/input-policy gauntlet for zero-width and IME-sensitive
   empty-state behavior.
4. Add test:slate-browser:cross only after that contract is stable.
5. Add test:slate-browser:perf and maybe test:slate-browser:accuracy
   after correctness lanes stop moving.
6. Keep the agent-native lane as a later extension seam, not the next core
   tranche.

Bottom Line Copy Chapter

The best future testing framework is:

• Lexical’s IME realism
• Slate’s example-driven Playwright harness
• edix and rich-textarea’s browser-contract speed
• Premirror’s determinism/perf discipline
• VS Code’s layered lane organization
• agent-browser/dev-browser for agent-native parity

Not:

• one runner
• one suite
• one fake jsdom composition test pretending it solved IME

Slate V2 Draft Overview (`docs/slate-v2-draft/overview.md`) Copy Section

date: 2026-04-08 topic: slate-v2-overview Copy Chapter

Slate v2 Overview

Purpose Copy Chapter

Front door to the live docs/slate-v2 stack.

Current Read Copy Chapter

• live verdict now treats Target A as Go on the proved default stack
• the broader Target B claim is still reopened under the exhaustive
  API/public-surface audit challenge
• the curated perf gate package currently clears on blocker-facing lanes in
  replacement-gates-scoreboard.md
• completed roadmap groundwork is now called POC RC
• the core packages/slate/test/** deleted-family bucket is closed
• the full packages/slate-react/** deleted-family bucket is closed
• the full packages/slate-history/** package bucket is closed
• major file/test deletion review is now explicitly closed
• extension model / behavior interception is now explicitly closed
• schema / normalization extensibility is now explicitly closed
• non-React / headless core usability is now explicitly closed
• operation-history-collaboration integrity is now explicitly closed
• the decoration source-scoped invalidation tranche is now the banked overlay
  authority, not the next broad blocker lane
• the earlier package-matrix public-surface pass is banked, but exhaustive
  API/public-surface contract-width audit remains reopened under challenge
• maximum parity with legacy for all examples is now reopened as a sibling
  blocker lane
• direct 1:1 legacy fixture proof now exists for Editor.nodes/** and the
  non-Editor interfaces/** namespaces
• the direct transform audit at
  /Users/zbeyens/git/slate-v2/packages/slate/test/legacy-transforms-fixtures.ts
  is green again, so the transform lane is no longer a blanket reopened family
• the remaining transform debt is narrower:
  • explicit-skip rows
• the overlay architecture lock is complete, and its next perfection tranche is
  active:
  • decoration sources own inline projected decoration
  • Bookmark owns durable public anchors
  • annotation stores own anchored data
  • widget stores own widget UI
• the broader program is still called True Slate RC
• the current execution owners are now:
  • 2026-04-13-slate-v2-full-no-regression-story-plan.md
  • 2026-04-15-slate-v2-example-parity-recovery-plan.md
  • decoration-roadmap.md
• browser/input external-evidence work is now post-RC follow-up, not the active
  current blocker lane
• local Firefox and Android structural/browser rows are exhausted; the current
  broader blocker lanes are exhaustive API/public-surface audit plus example
  parity, and external Android keyboard-feature evidence plus broader iOS
  evidence remain post-RC follow-up
• the zero-regression diff seed in
  true-slate-rc-proof-ledger.md
  is EMPTY, so there are no hidden unreviewed browser/input files left in the
  current scoped diff

Ownership Copy Chapter

Vocabulary Copy Chapter

Read In This Order Copy Chapter

1. release-readiness-decision.md
2. replacement-gates-scoreboard.md
3. replacement-family-ledger.md
4. master-roadmap.md
5. release-file-review-ledger.md
6. true-slate-rc-proof-ledger.md
7. decoration-roadmap.md
8. 2026-04-13-slate-v2-full-no-regression-story-plan.md
9. pr-description.md

Command Entry Copy Chapter

• commands/reconsolidate-roadmap.md
  is the command-pack entrypoint

Reference / Historical Specs Copy Chapter

• architecture-contract.md
• live-shape-register.md
• normalization-reference.md
• slate-batch-engine.md
• chunking-review.md

These do not own queue or verdict truth.

Current read:

• slate-batch-engine.md is legacy retrofit context, not active remaining-work
  ownership
• chunking-review.md is historical design analysis; the live runtime posture
  is selector-first rendering plus semantic islands, not child-count chunking

Slate V2 Overview (`docs/slate-v2/overview.md`) Copy Section

date: 2026-04-18 topic: slate-v2-overview status: active Copy Chapter

Slate v2 Overview

Purpose Copy Chapter

Front door to the live slate-v2 migration program.

This stack now describes the final-state program for the fresh .tmp/slate-v2
clone. It is not the old rewrite archive.

Current Read Copy Chapter

• .tmp/slate-v2 is the live target
• .tmp/slate-v2-draft is the evidence/value bank
• docs/slate-v2/** is the final-state spec lane
• docs/slate-v2-draft/** is the archived prior doc lane
• tranche 1 is complete:
  • Bun root/tooling graph
  • Bun test ownership
  • package-manifest build owners
  • docs ownership reset
• tranche 2 is complete:
  • React 19.2.5 baseline
  • Next 16.2.4 for the site/runtime lane
  • TypeScript 6.0.3 baseline
  • package-src HMR without package rebuilds
  • low-risk compatibility fallout only
• tranche 3 is the live redesign lane:
  • packages/slate is being redesigned toward the native transaction engine
    and snapshot/store-first API described in
    architecture-contract.md
  • support-package work stays blocked until the slate core API is honestly
    settled
  • backward compatibility is no longer the default value; compatibility keeps
    only what still earns its weight
  • hard cuts are allowed when retrofit baggage blocks the better API
  • current packages/slate proof and perf floors stay active guardrails while
    the redesign lands
• merged corpus docs now exist for:
  • slate
  • slate-history
  • slate-hyperscript
  • slate-dom
  • slate-react
• the live stack again has explicit north-star docs for:
  • absolute architecture release claim
  • post-closure proof hardening plan
  • architecture contract
  • overlay roadmap
  • decorations/annotations rationale
  • chunking rejection and huge-doc posture

Read Order Copy Chapter

1. absolute-architecture-release-claim.md
2. docs/plans/2026-04-25-slate-v2-editing-epoch-kernel-regression-closure-plan.md
3. docs/plans/2026-04-24-slate-v2-post-closure-proof-hardening-plan.md
4. docs/plans/2026-04-24-slate-v2-absolute-architecture-closure-plan.md
5. references/architecture-contract.md
6. master-roadmap.md
7. release-readiness-decision.md
8. replacement-gates-scoreboard.md
9. true-slate-rc-proof-ledger.md
10. fresh-branch-migration-plan.md
11. release-file-review-ledger.md
12. historical context only:
    2026-04-18-001-refactor-slate-v2-parity-first-migration-plan.md
13. decoration-roadmap.md
14. decorations-annotations-cluster.md
15. references/chunking-review.md
16. final-api-hard-cuts-status.md
17. pr-description.md
18. ledgers/README.md

Ownership Copy Chapter

Archive Rule Copy Chapter

If a doc belongs to the old rewrite program and is not live migration truth, it
belongs in docs/slate-v2-draft/**.

Editor Test Harvester Lexical Test Index (`docs/editor-test-harvester/lexical/test-index.md`) Copy Section

Lexical Portable Test-Name Index

source report: report.md
target: ../lexical
generated_at: 2026-05-08
last_consolidated_at: 2026-05-09
consolidation: portable runnable file count still 137; extracted line count still 1996; no missing or stale index files.

Indexed runnable portable and portable-mixed files: 137.
Extracted test/describe/it lines: 1996.
Files with zero extracted names: 0.

The extractor records literal, dynamic, and multiline titles by line pointer. Dynamic rows still need local reading before an apply pass, but they are no longer hidden behind a file-name-only route.

`../lexical/packages/lexical-code-shiki/src/__tests__/unit/LexicalCodeNodeTabs.test.ts` Copy Chapter

category: portable
family: core package behavior
target: .tmp/slate-v2/packages/slate/test; add focused browser proof only when behavior depends on DOM/runtime transport

• ../lexical/packages/lexical-code-shiki/src/__tests__/unit/LexicalCodeNodeTabs.test.ts:47 describe: LexicalCodeNode tests
• ../lexical/packages/lexical-code-shiki/src/__tests__/unit/LexicalCodeNodeTabs.test.ts:49 describe: Tabs
• ../lexical/packages/lexical-code-shiki/src/__tests__/unit/LexicalCodeNodeTabs.test.ts:96 test: testing ${scenario[2]}: ${scenario[0]} => ${scenario[1]} (${direction})

`../lexical/packages/lexical-code/src/__tests__/unit/LexicalCodeNode.test.ts` Copy Chapter

category: portable
family: core package behavior
target: .tmp/slate-v2/packages/slate/test; add focused browser proof only when behavior depends on DOM/runtime transport

• ../lexical/packages/lexical-code/src/__tests__/unit/LexicalCodeNode.test.ts:60 describe: LexicalCodeNode tests
• ../lexical/packages/lexical-code/src/__tests__/unit/LexicalCodeNode.test.ts:62 test: CodeNode.constructor
• ../lexical/packages/lexical-code/src/__tests__/unit/LexicalCodeNode.test.ts:73 test: CodeNode.createDOM()
• ../lexical/packages/lexical-code/src/__tests__/unit/LexicalCodeNode.test.ts:90 test: CodeNode.updateDOM()
• ../lexical/packages/lexical-code/src/__tests__/unit/LexicalCodeNode.test.ts:111 test: CodeNode.exportJSON() should return and object conforming to the expected schema
• ../lexical/packages/lexical-code/src/__tests__/unit/LexicalCodeNode.test.ts:133 test: CodeNode.insertNewAfter()
• ../lexical/packages/lexical-code/src/__tests__/unit/LexicalCodeNode.test.ts:167 test: $createCodeNode()
• ../lexical/packages/lexical-code/src/__tests__/unit/LexicalCodeNode.test.ts:179 test: can tab with collapsed selection
• ../lexical/packages/lexical-code/src/__tests__/unit/LexicalCodeNode.test.ts:215 test: can tab with non-collapsed selection
• ../lexical/packages/lexical-code/src/__tests__/unit/LexicalCodeNode.test.ts:239 test: can indent/outdent one line by forward selecting all line (with tabs)
• ../lexical/packages/lexical-code/src/__tests__/unit/LexicalCodeNode.test.ts:279 test: can indent/outdent one line by backward selecting all line (with tabs)
• ../lexical/packages/lexical-code/src/__tests__/unit/LexicalCodeNode.test.ts:319 test: can indent/outdent with collapsed selection at start of line (with tabs)
• ../lexical/packages/lexical-code/src/__tests__/unit/LexicalCodeNode.test.ts:357 test: can indent/outdent multiline (with tabs)
• ../lexical/packages/lexical-code/src/__tests__/unit/LexicalCodeNode.test.ts:391 test: can indent at the start of the second line
• ../lexical/packages/lexical-code/src/__tests__/unit/LexicalCodeNode.test.ts:409 test: can indent when selection has a CodeNode element (with indent)
• ../lexical/packages/lexical-code/src/__tests__/unit/LexicalCodeNode.test.ts:435 test: can outdent at arbitrary points in the line (with tabs)
• ../lexical/packages/lexical-code/src/__tests__/unit/LexicalCodeNode.test.ts:459 test: code blocks can shift lines (with tab)
• ../lexical/packages/lexical-code/src/__tests__/unit/LexicalCodeNode.test.ts:479 test: code blocks can shift multiple lines (with tab)
• ../lexical/packages/lexical-code/src/__tests__/unit/LexicalCodeNode.test.ts:513 describe: arrows
• ../lexical/packages/lexical-code/src/__tests__/unit/LexicalCodeNode.test.ts:514 describe: rtl code lines
• ../lexical/packages/lexical-code/src/__tests__/unit/LexicalCodeNode.test.ts:537 test: MOVE_TO_END moves caret to visual right
• ../lexical/packages/lexical-code/src/__tests__/unit/LexicalCodeNode.test.ts:559 test: MOVE_TO_START moves caret to visual left
• ../lexical/packages/lexical-code/src/__tests__/unit/LexicalCodeNode.test.ts:1006 describe: initial editor state before transforms
• ../lexical/packages/lexical-code/src/__tests__/unit/LexicalCodeNode.test.ts:1007 test: can be registered after initial editor state (regression #7014)

`../lexical/packages/lexical-code/src/__tests__/unit/LexicalCodeNodeTabs.test.ts` Copy Chapter

category: portable
family: core package behavior
target: .tmp/slate-v2/packages/slate/test; add focused browser proof only when behavior depends on DOM/runtime transport

• ../lexical/packages/lexical-code/src/__tests__/unit/LexicalCodeNodeTabs.test.ts:34 describe: LexicalCodeNode tests
• ../lexical/packages/lexical-code/src/__tests__/unit/LexicalCodeNodeTabs.test.ts:36 describe: Tabs
• ../lexical/packages/lexical-code/src/__tests__/unit/LexicalCodeNodeTabs.test.ts:83 test: testing ${scenario[2]}: ${scenario[0]} => ${scenario[1]} (${direction})

`../lexical/packages/lexical-history/src/__tests__/unit/LexicalHistory.test.tsx` Copy Chapter

category: portable
family: core package behavior
target: .tmp/slate-v2/packages/slate/test; add focused browser proof only when behavior depends on DOM/runtime transport

• ../lexical/packages/lexical-history/src/__tests__/unit/LexicalHistory.test.tsx:205 describe: LexicalHistory tests
• ../lexical/packages/lexical-history/src/__tests__/unit/LexicalHistory.test.tsx:248 test: LexicalHistory after clearing
• ../lexical/packages/lexical-history/src/__tests__/unit/LexicalHistory.test.tsx:284 test: LexicalHistory.Redo after Quote Node
• ../lexical/packages/lexical-history/src/__tests__/unit/LexicalHistory.test.tsx:352 test: LexicalHistory in sequence: change, undo, redo, undo, change
• ../lexical/packages/lexical-history/src/__tests__/unit/LexicalHistory.test.tsx:437 test: undoStack selection points to the same editor
• ../lexical/packages/lexical-history/src/__tests__/unit/LexicalHistory.test.tsx:481 test: Changes to TextNode leaf are detected properly #6409
• ../lexical/packages/lexical-history/src/__tests__/unit/LexicalHistory.test.tsx:541 describe: SharedHistoryExtension
• ../lexical/packages/lexical-history/src/__tests__/unit/LexicalHistory.test.tsx:542 test: can create a parent editor

`../lexical/packages/lexical-html/src/__tests__/unit/LexicalHtml.test.ts` Copy Chapter

category: portable
family: core package behavior
target: .tmp/slate-v2/packages/slate/test; add focused browser proof only when behavior depends on DOM/runtime transport

• ../lexical/packages/lexical-html/src/__tests__/unit/LexicalHtml.test.ts:25 describe: HTML
• ../lexical/packages/lexical-html/src/__tests__/unit/LexicalHtml.test.ts:42 test: [Lexical -> HTML]: ${name}
• ../lexical/packages/lexical-html/src/__tests__/unit/LexicalHtml.test.ts:64 test: [Lexical -> HTML]: Use provided selection
• ../lexical/packages/lexical-html/src/__tests__/unit/LexicalHtml.test.ts:111 test: [Lexical -> HTML]: Default selection (undefined) should serialize entire editor state
• ../lexical/packages/lexical-html/src/__tests__/unit/LexicalHtml.test.ts:156 test: dynamic or multiline title
• ../lexical/packages/lexical-html/src/__tests__/unit/LexicalHtml.test.ts:186 test: If alignment is set on the paragraph, it should take precedence over its parent block alignment
• ../lexical/packages/lexical-html/src/__tests__/unit/LexicalHtml.test.ts:216 test: It should output correctly nodes whose export is DocumentFragment

`../lexical/packages/lexical-list/src/__tests__/unit/LexicalListItemNode.test.ts` Copy Chapter

category: portable
family: serialization-parsing / marks-inline
target: .tmp/slate-v2/packages/slate/test; .tmp/slate-v2/packages/slate-history/test; .tmp/slate-v2/playwright/integration/examples/richtext.test.ts

• ../lexical/packages/lexical-list/src/__tests__/unit/LexicalListItemNode.test.ts:44 describe: LexicalListItemNode tests
• ../lexical/packages/lexical-list/src/__tests__/unit/LexicalListItemNode.test.ts:46 test: ListItemNode.constructor
• ../lexical/packages/lexical-list/src/__tests__/unit/LexicalListItemNode.test.ts:60 test: ListItemNode.createDOM()
• ../lexical/packages/lexical-list/src/__tests__/unit/LexicalListItemNode.test.ts:85 describe: ListItemNode.updateDOM()
• ../lexical/packages/lexical-list/src/__tests__/unit/LexicalListItemNode.test.ts:86 test: base
• ../lexical/packages/lexical-list/src/__tests__/unit/LexicalListItemNode.test.ts:119 test: nested list
• ../lexical/packages/lexical-list/src/__tests__/unit/LexicalListItemNode.test.ts:158 describe: ListItemNode.replace()
• ../lexical/packages/lexical-list/src/__tests__/unit/LexicalListItemNode.test.ts:206 test: another list item node
• ../lexical/packages/lexical-list/src/__tests__/unit/LexicalListItemNode.test.ts:239 test: first list item with a non list item node
• ../lexical/packages/lexical-list/src/__tests__/unit/LexicalListItemNode.test.ts:294 test: last list item with a non list item node
• ../lexical/packages/lexical-list/src/__tests__/unit/LexicalListItemNode.test.ts:323 test: middle list item with a non list item node
• ../lexical/packages/lexical-list/src/__tests__/unit/LexicalListItemNode.test.ts:354 test: the only list item with a non list item node
• ../lexical/packages/lexical-list/src/__tests__/unit/LexicalListItemNode.test.ts:397 describe: ListItemNode.remove()
• ../lexical/packages/lexical-list/src/__tests__/unit/LexicalListItemNode.test.ts:401 test: siblings are not nested
• ../lexical/packages/lexical-list/src/__tests__/unit/LexicalListItemNode.test.ts:469 test: the previous sibling is nested
• ../lexical/packages/lexical-list/src/__tests__/unit/LexicalListItemNode.test.ts:549 test: the next sibling is nested
• ../lexical/packages/lexical-list/src/__tests__/unit/LexicalListItemNode.test.ts:629 test: both siblings are nested
• ../lexical/packages/lexical-list/src/__tests__/unit/LexicalListItemNode.test.ts:718 test: the previous sibling is nested deeper than the next sibling
• ../lexical/packages/lexical-list/src/__tests__/unit/LexicalListItemNode.test.ts:828 test: the next sibling is nested deeper than the previous sibling
• ../lexical/packages/lexical-list/src/__tests__/unit/LexicalListItemNode.test.ts:939 test: both siblings are deeply nested
• ../lexical/packages/lexical-list/src/__tests__/unit/LexicalListItemNode.test.ts:1063 describe: ListItemNode.insertNewAfter(): non-empty list items
• ../lexical/packages/lexical-list/src/__tests__/unit/LexicalListItemNode.test.ts:1111 test: first list item
• ../lexical/packages/lexical-list/src/__tests__/unit/LexicalListItemNode.test.ts:1142 test: last list item
• ../lexical/packages/lexical-list/src/__tests__/unit/LexicalListItemNode.test.ts:1173 test: middle list item
• ../lexical/packages/lexical-list/src/__tests__/unit/LexicalListItemNode.test.ts:1204 test: the only list item
• ../lexical/packages/lexical-list/src/__tests__/unit/LexicalListItemNode.test.ts:1251 test: $createListItemNode()
• ../lexical/packages/lexical-list/src/__tests__/unit/LexicalListItemNode.test.ts:1265 test: $isListItemNode()
• ../lexical/packages/lexical-list/src/__tests__/unit/LexicalListItemNode.test.ts:1275 describe: ListItemNode.setIndent()
• ../lexical/packages/lexical-list/src/__tests__/unit/LexicalListItemNode.test.ts:1296 it: indents and outdents list item
• ../lexical/packages/lexical-list/src/__tests__/unit/LexicalListItemNode.test.ts:1356 it: handles fractional indent values
• ../lexical/packages/lexical-list/src/__tests__/unit/LexicalListItemNode.test.ts:1369 test: Can serialize a node that is not attached
• ../lexical/packages/lexical-list/src/__tests__/unit/LexicalListItemNode.test.ts:1388 test: ListItemNode marker style inheritance on indent
• ../lexical/packages/lexical-list/src/__tests__/unit/LexicalListItemNode.test.ts:1415 test: Default: Splitting a list resets numbering to 1 (Backward Compatibility)
• ../lexical/packages/lexical-list/src/__tests__/unit/LexicalListItemNode.test.ts:1455 test: Option Enabled: Splitting a list preserves numbering (Smart Behavior)

`../lexical/packages/lexical-list/src/__tests__/unit/LexicalListNode.test.ts` Copy Chapter

category: portable
family: serialization-parsing / marks-inline
target: .tmp/slate-v2/packages/slate/test; .tmp/slate-v2/packages/slate-history/test; .tmp/slate-v2/playwright/integration/examples/richtext.test.ts

• ../lexical/packages/lexical-list/src/__tests__/unit/LexicalListNode.test.ts:54 describe: LexicalListNode tests
• ../lexical/packages/lexical-list/src/__tests__/unit/LexicalListNode.test.ts:56 test: ListNode.constructor
• ../lexical/packages/lexical-list/src/__tests__/unit/LexicalListNode.test.ts:70 test: ListNode.getTag()
• ../lexical/packages/lexical-list/src/__tests__/unit/LexicalListNode.test.ts:83 test: ListNode.createDOM()
• ../lexical/packages/lexical-list/src/__tests__/unit/LexicalListNode.test.ts:108 test: ListNode.createDOM() correctly applies classes to a nested ListNode
• ../lexical/packages/lexical-list/src/__tests__/unit/LexicalListNode.test.ts:189 test: ListNode.updateDOM()
• ../lexical/packages/lexical-list/src/__tests__/unit/LexicalListNode.test.ts:214 test: ListNode.append() should properly transform a ListItemNode
• ../lexical/packages/lexical-list/src/__tests__/unit/LexicalListNode.test.ts:231 test: ListNode.append() should properly transform a ListNode
• ../lexical/packages/lexical-list/src/__tests__/unit/LexicalListNode.test.ts:253 test: ListNode.append() should properly transform a ParagraphNode
• ../lexical/packages/lexical-list/src/__tests__/unit/LexicalListNode.test.ts:269 test: ListNode.append() should wrap an InlineNode in a ListItemNode without converting it to TextNode
• ../lexical/packages/lexical-list/src/__tests__/unit/LexicalListNode.test.ts:308 test: ListNode.splice() should wrap multiple non-ListItem nodes in individual ListItem nodes
• ../lexical/packages/lexical-list/src/__tests__/unit/LexicalListNode.test.ts:341 test: Should update list children when switching from checklist to bullet
• ../lexical/packages/lexical-list/src/__tests__/unit/LexicalListNode.test.ts:367 test: Should clear checklist attributes when nesting lists
• ../lexical/packages/lexical-list/src/__tests__/unit/LexicalListNode.test.ts:425 test: $createListNode()
• ../lexical/packages/lexical-list/src/__tests__/unit/LexicalListNode.test.ts:439 test: $isListNode()
• ../lexical/packages/lexical-list/src/__tests__/unit/LexicalListNode.test.ts:449 test: $createListNode() with tag name (backward compatibility)
• ../lexical/packages/lexical-list/src/__tests__/unit/LexicalListNode.test.ts:462 describe: LexicalListNode subclassing tests ($config)
• ../lexical/packages/lexical-list/src/__tests__/unit/LexicalListNode.test.ts:494 describe: ListNode as-is
• ../lexical/packages/lexical-list/src/__tests__/unit/LexicalListNode.test.ts:497 test: applies transform
• ../lexical/packages/lexical-list/src/__tests__/unit/LexicalListNode.test.ts:513 describe: ListNodeConfig (no replacement)
• ../lexical/packages/lexical-list/src/__tests__/unit/LexicalListNode.test.ts:516 test: applies transform
• ../lexical/packages/lexical-list/src/__tests__/unit/LexicalListNode.test.ts:532 describe: ListNodeSubclass (no replacement)
• ../lexical/packages/lexical-list/src/__tests__/unit/LexicalListNode.test.ts:535 test: applies transform

`../lexical/packages/lexical-list/src/__tests__/unit/ListExtension.test.ts` Copy Chapter

category: portable
family: serialization-parsing / marks-inline
target: .tmp/slate-v2/packages/slate/test; .tmp/slate-v2/packages/slate-history/test; .tmp/slate-v2/playwright/integration/examples/richtext.test.ts

• ../lexical/packages/lexical-list/src/__tests__/unit/ListExtension.test.ts:23 describe: ListExtension
• ../lexical/packages/lexical-list/src/__tests__/unit/ListExtension.test.ts:36 it: Creates the list
• ../lexical/packages/lexical-list/src/__tests__/unit/ListExtension.test.ts:47 describe: CheckListExtension
• ../lexical/packages/lexical-list/src/__tests__/unit/ListExtension.test.ts:61 it: Preserves numbering when configured via extension
• ../lexical/packages/lexical-list/src/__tests__/unit/ListExtension.test.ts:118 it: Creates the list

`../lexical/packages/lexical-list/src/__tests__/unit/formatList.test.ts` Copy Chapter

category: portable
family: serialization-parsing / marks-inline
target: .tmp/slate-v2/packages/slate/test; .tmp/slate-v2/packages/slate-history/test; .tmp/slate-v2/playwright/integration/examples/richtext.test.ts

• ../lexical/packages/lexical-list/src/__tests__/unit/formatList.test.ts:82 describe: insertList
• ../lexical/packages/lexical-list/src/__tests__/unit/formatList.test.ts:84 test: inserting with empty root selection
• ../lexical/packages/lexical-list/src/__tests__/unit/formatList.test.ts:106 test: inserting in root selection with existing child
• ../lexical/packages/lexical-list/src/__tests__/unit/formatList.test.ts:131 test: inserting with empty shadow root selection
• ../lexical/packages/lexical-list/src/__tests__/unit/formatList.test.ts:160 test: formatting empty list items
• ../lexical/packages/lexical-list/src/__tests__/unit/formatList.test.ts:187 test: preserves element-anchored selection when converting paragraph with linebreak to list
• ../lexical/packages/lexical-list/src/__tests__/unit/formatList.test.ts:233 describe: $handleListInsertParagraph
• ../lexical/packages/lexical-list/src/__tests__/unit/formatList.test.ts:235 test: exits list when list item is completely empty
• ../lexical/packages/lexical-list/src/__tests__/unit/formatList.test.ts:262 test: exits list when list item contains only whitespace
• ../lexical/packages/lexical-list/src/__tests__/unit/formatList.test.ts:291 test: extends list when list item contains non-whitespace content
• ../lexical/packages/lexical-list/src/__tests__/unit/formatList.test.ts:317 test: extends list when list item contains a decorator node
• ../lexical/packages/lexical-list/src/__tests__/unit/formatList.test.ts:343 test: splits list when the empty element is not the last one
• ../lexical/packages/lexical-list/src/__tests__/unit/formatList.test.ts:386 describe: $handleIndent
• ../lexical/packages/lexical-list/src/__tests__/unit/formatList.test.ts:389 test: creates a new nested sublist
• ../lexical/packages/lexical-list/src/__tests__/unit/formatList.test.ts:422 describe: $handleOutdent
• ../lexical/packages/lexical-list/src/__tests__/unit/formatList.test.ts:424 test: removes the nested list and replaces list item

`../lexical/packages/lexical-list/src/__tests__/unit/registerListStrictIndentTransform.test.ts` Copy Chapter

category: portable
family: serialization-parsing / marks-inline
target: .tmp/slate-v2/packages/slate/test; .tmp/slate-v2/packages/slate-history/test; .tmp/slate-v2/playwright/integration/examples/richtext.test.ts

• ../lexical/packages/lexical-list/src/__tests__/unit/registerListStrictIndentTransform.test.ts:19 describe: Lexical List StrictIndentTransform tests
• ../lexical/packages/lexical-list/src/__tests__/unit/registerListStrictIndentTransform.test.ts:26 test: applyStrictListIndentation

`../lexical/packages/lexical-list/src/__tests__/unit/utils.test.ts` Copy Chapter

category: portable
family: core package behavior
target: .tmp/slate-v2/packages/slate/test; add focused browser proof only when behavior depends on DOM/runtime transport

• ../lexical/packages/lexical-list/src/__tests__/unit/utils.test.ts:15 describe: Lexical List Utils tests
• ../lexical/packages/lexical-list/src/__tests__/unit/utils.test.ts:17 test: getListDepth should return the 1-based depth of a list with one levels
• ../lexical/packages/lexical-list/src/__tests__/unit/utils.test.ts:35 test: getListDepth should return the 1-based depth of a list with two levels
• ../lexical/packages/lexical-list/src/__tests__/unit/utils.test.ts:68 test: getListDepth should return the 1-based depth of a list with five levels
• ../lexical/packages/lexical-list/src/__tests__/unit/utils.test.ts:113 test: getTopListNode should return the top list node when the list is a direct child of the RootNode
• ../lexical/packages/lexical-list/src/__tests__/unit/utils.test.ts:144 test: getTopListNode should return the top list node when the list is not a direct child of the RootNode
• ../lexical/packages/lexical-list/src/__tests__/unit/utils.test.ts:176 test: getTopListNode should return the top list node when the list item is deeply nested.
• ../lexical/packages/lexical-list/src/__tests__/unit/utils.test.ts:214 test: isLastItemInList should return true if the listItem is the last in a nested list.
• ../lexical/packages/lexical-list/src/__tests__/unit/utils.test.ts:249 test: isLastItemInList should return true if the listItem is the last in a non-nested list.
• ../lexical/packages/lexical-list/src/__tests__/unit/utils.test.ts:275 test: isLastItemInList should return false if the listItem is not the last in a nested list.
• ../lexical/packages/lexical-list/src/__tests__/unit/utils.test.ts:310 test: isLastItemInList should return true if the listItem is not the last in a non-nested list.

`../lexical/packages/lexical-markdown/src/__tests__/unit/LexicalMarkdown.test.ts` Copy Chapter

category: portable
family: serialization-parsing / marks-inline
target: .tmp/slate-v2/packages/slate/test; .tmp/slate-v2/packages/slate-history/test; .tmp/slate-v2/playwright/integration/examples/richtext.test.ts

• ../lexical/packages/lexical-markdown/src/__tests__/unit/LexicalMarkdown.test.ts:257 describe: Markdown
• ../lexical/packages/lexical-markdown/src/__tests__/unit/LexicalMarkdown.test.ts:818 it: dynamic or multiline title
• ../lexical/packages/lexical-markdown/src/__tests__/unit/LexicalMarkdown.test.ts:866 it: dynamic or multiline title
• ../lexical/packages/lexical-markdown/src/__tests__/unit/LexicalMarkdown.test.ts:916 it: dynamic or multiline title
• ../lexical/packages/lexical-markdown/src/__tests__/unit/LexicalMarkdown.test.ts:950 it: should not remove leading node and transform if replace returns false
• ../lexical/packages/lexical-markdown/src/__tests__/unit/LexicalMarkdown.test.ts:997 it: should remove leading node and execute transform if replace does not return false
• ../lexical/packages/lexical-markdown/src/__tests__/unit/LexicalMarkdown.test.ts:1044 it: can round-trip nested fenced code blocks (4 backticks wrapping 3 backticks)
• ../lexical/packages/lexical-markdown/src/__tests__/unit/LexicalMarkdown.test.ts:1080 it: can round-trip deeply nested fenced code blocks (5 backticks wrapping 4 backticks)
• ../lexical/packages/lexical-markdown/src/__tests__/unit/LexicalMarkdown.test.ts:1117 it: computes fence dynamically when code block content contains backticks
• ../lexical/packages/lexical-markdown/src/__tests__/unit/LexicalMarkdown.test.ts:1145 describe: list marker
• ../lexical/packages/lexical-markdown/src/__tests__/unit/LexicalMarkdown.test.ts:1146 it: should remember marker used on import
• ../lexical/packages/lexical-markdown/src/__tests__/unit/LexicalMarkdown.test.ts:1168 it: should not use [ as a marker for an implicit check list
• ../lexical/packages/lexical-markdown/src/__tests__/unit/LexicalMarkdown.test.ts:1192 it: should remember the marker for checkbox with an explicit marker
• ../lexical/packages/lexical-markdown/src/__tests__/unit/LexicalMarkdown.test.ts:1217 it: should remember marker used on export
• ../lexical/packages/lexical-markdown/src/__tests__/unit/LexicalMarkdown.test.ts:1245 describe: Enter key triggers
• ../lexical/packages/lexical-markdown/src/__tests__/unit/LexicalMarkdown.test.ts:1246 it: dynamic or multiline title
• ../lexical/packages/lexical-markdown/src/__tests__/unit/LexicalMarkdown.test.ts:1286 it: dynamic or multiline title
• ../lexical/packages/lexical-markdown/src/__tests__/unit/LexicalMarkdown.test.ts:1326 it: should not transform on Enter when replace returns false
• ../lexical/packages/lexical-markdown/src/__tests__/unit/LexicalMarkdown.test.ts:1381 describe: normalizeMarkdown - shouldMergeAdjacentLines = true
• ../lexical/packages/lexical-markdown/src/__tests__/unit/LexicalMarkdown.test.ts:1382 it: should combine lines separated by a single \n unless they are in a codeblock
• ../lexical/packages/lexical-markdown/src/__tests__/unit/LexicalMarkdown.test.ts:1446 it: tables
• ../lexical/packages/lexical-markdown/src/__tests__/unit/LexicalMarkdown.test.ts:1455 it: merges adjacent plain text lines with a single space
• ../lexical/packages/lexical-markdown/src/__tests__/unit/LexicalMarkdown.test.ts:1461 it: merges while trimming the next line and inserting a single space
• ../lexical/packages/lexical-markdown/src/__tests__/unit/LexicalMarkdown.test.ts:1467 it: does not merge across HTML-like tags (opening, content, closing, after)
• ../lexical/packages/lexical-markdown/src/__tests__/unit/LexicalMarkdown.test.ts:1476 it: does not merge the fence line with the first line after a code block
• ../lexical/packages/lexical-markdown/src/__tests__/unit/LexicalMarkdown.test.ts:1482 it: trims hard-break trailing spaces when merging adjacent lines
• ../lexical/packages/lexical-markdown/src/__tests__/unit/LexicalMarkdown.test.ts:1488 it: treats whitespace-only lines as empty separators (no merge across them)
• ../lexical/packages/lexical-markdown/src/__tests__/unit/LexicalMarkdown.test.ts:1498 it: mdx start tag followed by content, than closing tag preceded by content
• ../lexical/packages/lexical-markdown/src/__tests__/unit/LexicalMarkdown.test.ts:1507 describe: normalizeMarkdown - shouldMergeAdjacentLines = false
• ../lexical/packages/lexical-markdown/src/__tests__/unit/LexicalMarkdown.test.ts:1508 it: should not combine lines separated by a single \n
• ../lexical/packages/lexical-markdown/src/__tests__/unit/LexicalMarkdown.test.ts:1575 it: tables
• ../lexical/packages/lexical-markdown/src/__tests__/unit/LexicalMarkdown.test.ts:1584 it: preserves trailing whitespace on content lines
• ../lexical/packages/lexical-markdown/src/__tests__/unit/LexicalMarkdown.test.ts:1589 it: collapses whitespace-only lines to empty (paragraph separator)
• ../lexical/packages/lexical-markdown/src/__tests__/unit/LexicalMarkdown.test.ts:1594 it: preserves leading whitespace on content lines
• ../lexical/packages/lexical-markdown/src/__tests__/unit/LexicalMarkdown.test.ts:1600 describe: markdown hard line break import
• ../lexical/packages/lexical-markdown/src/__tests__/unit/LexicalMarkdown.test.ts:1601 it: preserves hard line break when shouldPreserveNewLines is true
• ../lexical/packages/lexical-markdown/src/__tests__/unit/LexicalMarkdown.test.ts:1641 it: preserves backslash hard line break when shouldPreserveNewLines is true
• ../lexical/packages/lexical-markdown/src/__tests__/unit/LexicalMarkdown.test.ts:1682 describe: markdown whitespace import (default mode)
• ../lexical/packages/lexical-markdown/src/__tests__/unit/LexicalMarkdown.test.ts:1696 it: preserves trailing whitespace on a standalone paragraph line (default mode)
• ../lexical/packages/lexical-markdown/src/__tests__/unit/LexicalMarkdown.test.ts:1722 it: preserves leading whitespace on a standalone paragraph line (default mode)
• ../lexical/packages/lexical-markdown/src/__tests__/unit/LexicalMarkdown.test.ts:1747 it: handles two-space hard line break in default mode (adjacent lines merged into LineBreak)

`../lexical/packages/lexical-markdown/src/__tests__/unit/MarkdownTransformers.test.ts` Copy Chapter

category: portable
family: serialization-parsing / marks-inline
target: .tmp/slate-v2/packages/slate/test; .tmp/slate-v2/packages/slate-history/test; .tmp/slate-v2/playwright/integration/examples/richtext.test.ts

• ../lexical/packages/lexical-markdown/src/__tests__/unit/MarkdownTransformers.test.ts:52 describe: LINK
• ../lexical/packages/lexical-markdown/src/__tests__/unit/MarkdownTransformers.test.ts:53 test: text before a markdown link is preserved
• ../lexical/packages/lexical-markdown/src/__tests__/unit/MarkdownTransformers.test.ts:68 test: formatted text before a markdown link is preserved
• ../lexical/packages/lexical-markdown/src/__tests__/unit/MarkdownTransformers.test.ts:90 test: LINK is not too greedy if there is a preceding match that was not processed
• ../lexical/packages/lexical-markdown/src/__tests__/unit/MarkdownTransformers.test.ts:123 test: markdown link should not be created inside another link.

`../lexical/packages/lexical-playground/__tests__/e2e/AutoLinks.spec.mjs` Copy Chapter

category: portable-mixed
family: selection-dom-mapping / void-atom
target: .tmp/slate-v2/packages/slate/test; .tmp/slate-v2/packages/slate-react/test/editable-behavior.test.tsx; .tmp/slate-v2/playwright/stress/generated-editing.test.ts

• ../lexical/packages/lexical-playground/__tests__/e2e/AutoLinks.spec.mjs:29 describe: Auto Links
• ../lexical/packages/lexical-playground/__tests__/e2e/AutoLinks.spec.mjs:32 test: Can convert url-like text into links
• ../lexical/packages/lexical-playground/__tests__/e2e/AutoLinks.spec.mjs:33 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/AutoLinks.spec.mjs:63 test: Can convert url-like text into links for email
• ../lexical/packages/lexical-playground/__tests__/e2e/AutoLinks.spec.mjs:67 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/AutoLinks.spec.mjs:92 test: Can destruct links if add non-spacing text in front or right after it
• ../lexical/packages/lexical-playground/__tests__/e2e/AutoLinks.spec.mjs:96 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/AutoLinks.spec.mjs:156 test: Can create link when pasting text with urls
• ../lexical/packages/lexical-playground/__tests__/e2e/AutoLinks.spec.mjs:160 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/AutoLinks.spec.mjs:191 test: Can create link for email when pasting text with urls
• ../lexical/packages/lexical-playground/__tests__/e2e/AutoLinks.spec.mjs:195 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/AutoLinks.spec.mjs:225 test: Does not create redundant auto-link
• ../lexical/packages/lexical-playground/__tests__/e2e/AutoLinks.spec.mjs:226 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/AutoLinks.spec.mjs:263 test: Can create links when pasting text with multiple autolinks in a row separated by non-alphanumeric characters, but not whitespaces
• ../lexical/packages/lexical-playground/__tests__/e2e/AutoLinks.spec.mjs:267 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/AutoLinks.spec.mjs:300 test: Handles multiple autolinks in a row
• ../lexical/packages/lexical-playground/__tests__/e2e/AutoLinks.spec.mjs:301 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/AutoLinks.spec.mjs:337 test: Handles autolink following an invalid autolink
• ../lexical/packages/lexical-playground/__tests__/e2e/AutoLinks.spec.mjs:341 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/AutoLinks.spec.mjs:360 test: Handles autolink following an invalid autolink to email
• ../lexical/packages/lexical-playground/__tests__/e2e/AutoLinks.spec.mjs:364 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/AutoLinks.spec.mjs:391 test: Can convert url-like text with formatting into links
• ../lexical/packages/lexical-playground/__tests__/e2e/AutoLinks.spec.mjs:395 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/AutoLinks.spec.mjs:440 test: Can convert url-like text with styles into links
• ../lexical/packages/lexical-playground/__tests__/e2e/AutoLinks.spec.mjs:444 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/AutoLinks.spec.mjs:491 test: Can convert URL into an autolink
• ../lexical/packages/lexical-playground/__tests__/e2e/AutoLinks.spec.mjs:542 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/AutoLinks.spec.mjs:543 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/AutoLinks.spec.mjs:567 test: Can convert URL into an email autolink
• ../lexical/packages/lexical-playground/__tests__/e2e/AutoLinks.spec.mjs:583 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/AutoLinks.spec.mjs:584 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/AutoLinks.spec.mjs:607 test: Can not convert bad URLs into links
• ../lexical/packages/lexical-playground/__tests__/e2e/AutoLinks.spec.mjs:639 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/AutoLinks.spec.mjs:655 test: Can not convert bad URLs into email links
• ../lexical/packages/lexical-playground/__tests__/e2e/AutoLinks.spec.mjs:678 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/AutoLinks.spec.mjs:694 test: Can unlink the autolink and then make it link again
• ../lexical/packages/lexical-playground/__tests__/e2e/AutoLinks.spec.mjs:698 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/AutoLinks.spec.mjs:755 test: Unlinked autolink is preserved when adding punctuation before or after it
• ../lexical/packages/lexical-playground/__tests__/e2e/AutoLinks.spec.mjs:759 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/AutoLinks.spec.mjs:842 test: Adding an invalid character will destruct an unlinked autolink
• ../lexical/packages/lexical-playground/__tests__/e2e/AutoLinks.spec.mjs:846 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/AutoLinks.spec.mjs:896 test: Adding an emoji inside an unlinked autolink will destruct it
• ../lexical/packages/lexical-playground/__tests__/e2e/AutoLinks.spec.mjs:900 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/AutoLinks.spec.mjs:955 test: Pressing Enter inside an AutoLinkNode does not insert extra paragraph
• ../lexical/packages/lexical-playground/__tests__/e2e/AutoLinks.spec.mjs:959 test: dynamic or multiline title

`../lexical/packages/lexical-playground/__tests__/e2e/AutoScroll.spec.mjs` Copy Chapter

category: portable
family: beforeinput-input / browser-engine
target: .tmp/slate-v2/packages/slate-react/test/model-input-strategy-contract.test.ts; .tmp/slate-v2/playwright/stress/generated-editing.test.ts

• ../lexical/packages/lexical-playground/__tests__/e2e/AutoScroll.spec.mjs:17 test: Auto scroll while typing
• ../lexical/packages/lexical-playground/__tests__/e2e/AutoScroll.spec.mjs:66 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/AutoScroll.spec.mjs:69 test: dynamic or multiline title

`../lexical/packages/lexical-playground/__tests__/e2e/Autocomplete.spec.mjs` Copy Chapter

category: portable-mixed
family: mixed portable invariant
target: .tmp/slate-v2/packages/slate/test; add focused browser proof only when behavior depends on DOM/runtime transport

• ../lexical/packages/lexical-playground/__tests__/e2e/Autocomplete.spec.mjs:27 test: Autocomplete
• ../lexical/packages/lexical-playground/__tests__/e2e/Autocomplete.spec.mjs:31 test: Can autocomplete a word
• ../lexical/packages/lexical-playground/__tests__/e2e/Autocomplete.spec.mjs:79 test: Can autocomplete in the same format as the original text
• ../lexical/packages/lexical-playground/__tests__/e2e/Autocomplete.spec.mjs:83 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/Autocomplete.spec.mjs:161 test: Undo does not cause an exception
• ../lexical/packages/lexical-playground/__tests__/e2e/Autocomplete.spec.mjs:166 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/Autocomplete.spec.mjs:168 test: dynamic or multiline title

`../lexical/packages/lexical-playground/__tests__/e2e/CharacterLimit.spec.mjs` Copy Chapter

category: portable-mixed
family: mixed portable invariant
target: .tmp/slate-v2/packages/slate/test; add focused browser proof only when behavior depends on DOM/runtime transport

• ../lexical/packages/lexical-playground/__tests__/e2e/CharacterLimit.spec.mjs:24 test: displays overflow on text
• ../lexical/packages/lexical-playground/__tests__/e2e/CharacterLimit.spec.mjs:25 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/CharacterLimit.spec.mjs:82 test: handles auto link nodes
• ../lexical/packages/lexical-playground/__tests__/e2e/CharacterLimit.spec.mjs:83 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/CharacterLimit.spec.mjs:124 test: displays overflow on token nodes
• ../lexical/packages/lexical-playground/__tests__/e2e/CharacterLimit.spec.mjs:130 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/CharacterLimit.spec.mjs:160 test: can type new lines inside overflow
• ../lexical/packages/lexical-playground/__tests__/e2e/CharacterLimit.spec.mjs:165 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/CharacterLimit.spec.mjs:215 test: can delete text in front and overflow is recomputed
• ../lexical/packages/lexical-playground/__tests__/e2e/CharacterLimit.spec.mjs:220 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/CharacterLimit.spec.mjs:287 test: can delete text in front and overflow is recomputed (token nodes)
• ../lexical/packages/lexical-playground/__tests__/e2e/CharacterLimit.spec.mjs:291 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/CharacterLimit.spec.mjs:332 test: can overflow in lists
• ../lexical/packages/lexical-playground/__tests__/e2e/CharacterLimit.spec.mjs:333 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/CharacterLimit.spec.mjs:353 test: can delete an overflowed paragraph
• ../lexical/packages/lexical-playground/__tests__/e2e/CharacterLimit.spec.mjs:358 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/CharacterLimit.spec.mjs:393 test: handles accented characters
• ../lexical/packages/lexical-playground/__tests__/e2e/CharacterLimit.spec.mjs:394 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/CharacterLimit.spec.mjs:426 test: handles graphemes
• ../lexical/packages/lexical-playground/__tests__/e2e/CharacterLimit.spec.mjs:427 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/CharacterLimit.spec.mjs:444 test: CharacterLimit
• ../lexical/packages/lexical-playground/__tests__/e2e/CharacterLimit.spec.mjs:445 test: UTF-16
• ../lexical/packages/lexical-playground/__tests__/e2e/CharacterLimit.spec.mjs:453 test: UTF-8

`../lexical/packages/lexical-playground/__tests__/e2e/ClearFormatting.spec.mjs` Copy Chapter

category: portable
family: serialization-parsing / marks-inline
target: .tmp/slate-v2/packages/slate/test; .tmp/slate-v2/packages/slate-history/test; .tmp/slate-v2/playwright/integration/examples/richtext.test.ts

• ../lexical/packages/lexical-playground/__tests__/e2e/ClearFormatting.spec.mjs:34 test: Clear All Formatting
• ../lexical/packages/lexical-playground/__tests__/e2e/ClearFormatting.spec.mjs:36 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/ClearFormatting.spec.mjs:39 test: Can clear BIU formatting
• ../lexical/packages/lexical-playground/__tests__/e2e/ClearFormatting.spec.mjs:60 test: Should preserve the default styling of links and quoted text
• ../lexical/packages/lexical-playground/__tests__/e2e/ClearFormatting.spec.mjs:107 test: Should preserve the default styling of hashtags and mentions
• ../lexical/packages/lexical-playground/__tests__/e2e/ClearFormatting.spec.mjs:188 test: Can clear left/center/right alignment when BIU formatting already applied
• ../lexical/packages/lexical-playground/__tests__/e2e/ClearFormatting.spec.mjs:210 test: Can clear left/center/right alignment when BIU formatting not applied
• ../lexical/packages/lexical-playground/__tests__/e2e/ClearFormatting.spec.mjs:231 test: Can clear when only indent/outdent alignment is applied
• ../lexical/packages/lexical-playground/__tests__/e2e/ClearFormatting.spec.mjs:252 test: Can clear indent/outdent alignment when other formatting options like BIU or left/right/center align are also applied
• ../lexical/packages/lexical-playground/__tests__/e2e/ClearFormatting.spec.mjs:279 test: Should clear formatting of selected text which spans over 1 paragraph

`../lexical/packages/lexical-playground/__tests__/e2e/CodeBlock.spec.mjs` Copy Chapter

category: portable
family: serialization-parsing / marks-inline
target: .tmp/slate-v2/packages/slate/test; .tmp/slate-v2/packages/slate-history/test; .tmp/slate-v2/playwright/integration/examples/richtext.test.ts

• ../lexical/packages/lexical-playground/__tests__/e2e/CodeBlock.spec.mjs:34 test: CodeBlock
• ../lexical/packages/lexical-playground/__tests__/e2e/CodeBlock.spec.mjs:36 test: Can create code block with markdown
• ../lexical/packages/lexical-playground/__tests__/e2e/CodeBlock.spec.mjs:108 test: Can create code block with markdown and wrap existing text
• ../lexical/packages/lexical-playground/__tests__/e2e/CodeBlock.spec.mjs:173 test: Can select multiple paragraphs and convert to code block
• ../lexical/packages/lexical-playground/__tests__/e2e/CodeBlock.spec.mjs:177 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/CodeBlock.spec.mjs:234 test: Can select partial paragraphs and convert to code block
• ../lexical/packages/lexical-playground/__tests__/e2e/CodeBlock.spec.mjs:238 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/CodeBlock.spec.mjs:300 test: Can select a line within line breaks and convert to code block
• ../lexical/packages/lexical-playground/__tests__/e2e/CodeBlock.spec.mjs:304 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/CodeBlock.spec.mjs:351 test: Can switch highlighting language in a toolbar
• ../lexical/packages/lexical-playground/__tests__/e2e/CodeBlock.spec.mjs:423 test: Can maintain indent when creating new lines
• ../lexical/packages/lexical-playground/__tests__/e2e/CodeBlock.spec.mjs:428 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/CodeBlock.spec.mjs:515 test: Can indent text via tab when selecting the line with Shift+Down
• ../lexical/packages/lexical-playground/__tests__/e2e/CodeBlock.spec.mjs:520 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/CodeBlock.spec.mjs:603 test: Can (un)indent multiple lines at once
• ../lexical/packages/lexical-playground/__tests__/e2e/CodeBlock.spec.mjs:608 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/CodeBlock.spec.mjs:924 test: Can move around lines with option+arrow keys
• ../lexical/packages/lexical-playground/__tests__/e2e/CodeBlock.spec.mjs:928 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/CodeBlock.spec.mjs:1111 test: prevents selection and typing outside code block boundaries
• ../lexical/packages/lexical-playground/__tests__/e2e/CodeBlock.spec.mjs:1115 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/CodeBlock.spec.mjs:1267 test: When pressing CMD/Ctrl + Left, CMD/Ctrl + Right, the cursor should go to the start of the code
• ../lexical/packages/lexical-playground/__tests__/e2e/CodeBlock.spec.mjs:1271 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/CodeBlock.spec.mjs:1350 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/CodeBlock.spec.mjs:1410 test: dynamic or multiline title

`../lexical/packages/lexical-playground/__tests__/e2e/Collaboration.spec.mjs` Copy Chapter

category: portable
family: collaboration-remote / history-undo-redo
target: .tmp/slate-v2/packages/slate/test/collab-history-runtime-contract.ts; future slate-yjs browser lane

• ../lexical/packages/lexical-playground/__tests__/e2e/Collaboration.spec.mjs:33 test: Collaboration
• ../lexical/packages/lexical-playground/__tests__/e2e/Collaboration.spec.mjs:36 test: Undo with collaboration on
• ../lexical/packages/lexical-playground/__tests__/e2e/Collaboration.spec.mjs:42 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/Collaboration.spec.mjs:220 test: Remove dangling text from YJS when there is no preceding text node
• ../lexical/packages/lexical-playground/__tests__/e2e/Collaboration.spec.mjs:226 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/Collaboration.spec.mjs:295 test: Merge dangling text into preceding text node
• ../lexical/packages/lexical-playground/__tests__/e2e/Collaboration.spec.mjs:301 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/Collaboration.spec.mjs:387 test: Undo/redo where text node is split by formatting change
• ../lexical/packages/lexical-playground/__tests__/e2e/Collaboration.spec.mjs:393 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/Collaboration.spec.mjs:512 test: Undo/redo where text node is split by inline element node
• ../lexical/packages/lexical-playground/__tests__/e2e/Collaboration.spec.mjs:518 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/Collaboration.spec.mjs:644 test: $handleNormalizationMergeConflicts handles nodes that have been reparented
• ../lexical/packages/lexical-playground/__tests__/e2e/Collaboration.spec.mjs:648 test: dynamic or multiline title

`../lexical/packages/lexical-playground/__tests__/e2e/ColumnLayoutBackspaceAtEnd.spec.mjs` Copy Chapter

category: portable-mixed
family: mixed portable invariant
target: .tmp/slate-v2/packages/slate/test; add focused browser proof only when behavior depends on DOM/runtime transport

• ../lexical/packages/lexical-playground/__tests__/e2e/ColumnLayoutBackspaceAtEnd.spec.mjs:17 test: Layout - removes layout completely when both columns are empty and backspace is pressed at the first layout item
• ../lexical/packages/lexical-playground/__tests__/e2e/ColumnLayoutBackspaceAtEnd.spec.mjs:22 test: dynamic or multiline title

`../lexical/packages/lexical-playground/__tests__/e2e/Composition.spec.mjs` Copy Chapter

category: portable
family: ime-composition / history-undo-redo
target: .tmp/slate-v2/playwright/stress/generated-editing.test.ts; .tmp/slate-v2/packages/slate-browser/src/playwright/ime.ts; .tmp/slate-v2/packages/slate-history/test

• ../lexical/packages/lexical-playground/__tests__/e2e/Composition.spec.mjs:33 test: Composition
• ../lexical/packages/lexical-playground/__tests__/e2e/Composition.spec.mjs:35 test: Handles Hiragana characters
• ../lexical/packages/lexical-playground/__tests__/e2e/Composition.spec.mjs:88 test: Handles Arabic characters with diacritics
• ../lexical/packages/lexical-playground/__tests__/e2e/Composition.spec.mjs:173 test: IME
• ../lexical/packages/lexical-playground/__tests__/e2e/Composition.spec.mjs:174 test: Can type Hiragana via IME
• ../lexical/packages/lexical-playground/__tests__/e2e/Composition.spec.mjs:176 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/Composition.spec.mjs:258 test: Can type Hiragana via IME between line breaks
• ../lexical/packages/lexical-playground/__tests__/e2e/Composition.spec.mjs:263 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/Composition.spec.mjs:371 test: Can type Hiragana via IME into a new bold format
• ../lexical/packages/lexical-playground/__tests__/e2e/Composition.spec.mjs:377 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/Composition.spec.mjs:445 test: Can type Hiragana via IME between emojis
• ../lexical/packages/lexical-playground/__tests__/e2e/Composition.spec.mjs:449 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/Composition.spec.mjs:636 test: Can type Hiragana via IME at the end of a mention
• ../lexical/packages/lexical-playground/__tests__/e2e/Composition.spec.mjs:641 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/Composition.spec.mjs:746 test: Can type Hiragana via IME part way through a mention
• ../lexical/packages/lexical-playground/__tests__/e2e/Composition.spec.mjs:751 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/Composition.spec.mjs:852 test: Typing after mention with IME should not break it
• ../lexical/packages/lexical-playground/__tests__/e2e/Composition.spec.mjs:858 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/Composition.spec.mjs:920 test: Can type Hiragana via IME with hashtags
• ../lexical/packages/lexical-playground/__tests__/e2e/Composition.spec.mjs:926 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/Composition.spec.mjs:1078 test: Can type, delete and cancel Hiragana via IME
• ../lexical/packages/lexical-playground/__tests__/e2e/Composition.spec.mjs:1083 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/Composition.spec.mjs:1211 test: Floating toolbar should not be displayed when using IME
• ../lexical/packages/lexical-playground/__tests__/e2e/Composition.spec.mjs:1217 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/Composition.spec.mjs:1276 test: Typeahead menu should not close during IME composition
• ../lexical/packages/lexical-playground/__tests__/e2e/Composition.spec.mjs:1281 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/Composition.spec.mjs:1325 test: Can replace multiple formatted text nodes with IME composition (Korean)
• ../lexical/packages/lexical-playground/__tests__/e2e/Composition.spec.mjs:1331 test: dynamic or multiline title

`../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/HTMLCopyAndPaste.spec.mjs` Copy Chapter

category: portable
family: clipboard-paste / browser-engine
target: .tmp/slate-v2/packages/slate/test/clipboard-contract.ts; .tmp/slate-v2/packages/slate-dom/test/clipboard-boundary.test.ts; .tmp/slate-v2/playwright/integration/examples/paste-html.test.ts; .tmp/slate-v2/playwright/stress/generated-editing.test.ts

• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/HTMLCopyAndPaste.spec.mjs:22 test: HTML CopyAndPaste
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/HTMLCopyAndPaste.spec.mjs:25 test: Copy + paste multi line html with extra newlines
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/HTMLCopyAndPaste.spec.mjs:30 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/HTMLCopyAndPaste.spec.mjs:53 test: Copy + paste a code block with BR
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/HTMLCopyAndPaste.spec.mjs:54 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/HTMLCopyAndPaste.spec.mjs:135 test: Copy + paste a paragraph element between horizontal rules
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/HTMLCopyAndPaste.spec.mjs:140 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/HTMLCopyAndPaste.spec.mjs:199 test: Paste top level element in the middle of paragraph
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/HTMLCopyAndPaste.spec.mjs:204 test: dynamic or multiline title

`../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/ImageHTMLCopyAndPaste.spec.mjs` Copy Chapter

category: portable
family: clipboard-paste / browser-engine
target: .tmp/slate-v2/packages/slate/test/clipboard-contract.ts; .tmp/slate-v2/packages/slate-dom/test/clipboard-boundary.test.ts; .tmp/slate-v2/playwright/integration/examples/paste-html.test.ts; .tmp/slate-v2/playwright/stress/generated-editing.test.ts

• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/ImageHTMLCopyAndPaste.spec.mjs:26 test: HTML Image CopyAndPaste
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/ImageHTMLCopyAndPaste.spec.mjs:31 test: Copy + paste HTML of a figure with img and figcaption
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/ImageHTMLCopyAndPaste.spec.mjs:37 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/ImageHTMLCopyAndPaste.spec.mjs:134 test: Copy + paste an image
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/ImageHTMLCopyAndPaste.spec.mjs:135 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/ImageHTMLCopyAndPaste.spec.mjs:172 test: Copy + paste + undo multiple image
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/ImageHTMLCopyAndPaste.spec.mjs:177 test: dynamic or multiline title

`../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/LinksHTMLCopyAndPaste.spec.mjs` Copy Chapter

category: portable
family: clipboard-paste / browser-engine
target: .tmp/slate-v2/packages/slate/test/clipboard-contract.ts; .tmp/slate-v2/packages/slate-dom/test/clipboard-boundary.test.ts; .tmp/slate-v2/playwright/integration/examples/paste-html.test.ts; .tmp/slate-v2/playwright/stress/generated-editing.test.ts

• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/LinksHTMLCopyAndPaste.spec.mjs:34 test: HTML Links CopyAndPaste
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/LinksHTMLCopyAndPaste.spec.mjs:37 test: Copy + paste an anchor element
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/LinksHTMLCopyAndPaste.spec.mjs:38 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/LinksHTMLCopyAndPaste.spec.mjs:99 test: Copy + paste in front of or after a link
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/LinksHTMLCopyAndPaste.spec.mjs:103 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/LinksHTMLCopyAndPaste.spec.mjs:130 test: Copy + paste link by selecting its (partial) content
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/LinksHTMLCopyAndPaste.spec.mjs:134 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/LinksHTMLCopyAndPaste.spec.mjs:166 test: Copy + paste empty link #3193
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/LinksHTMLCopyAndPaste.spec.mjs:167 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/LinksHTMLCopyAndPaste.spec.mjs:213 test: Paste a link into text
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/LinksHTMLCopyAndPaste.spec.mjs:214 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/LinksHTMLCopyAndPaste.spec.mjs:247 test: Paste text into a link
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/LinksHTMLCopyAndPaste.spec.mjs:248 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/LinksHTMLCopyAndPaste.spec.mjs:284 test: Paste formatted text into a link
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/LinksHTMLCopyAndPaste.spec.mjs:285 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/LinksHTMLCopyAndPaste.spec.mjs:326 test: Paste a link into a link
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/LinksHTMLCopyAndPaste.spec.mjs:327 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/LinksHTMLCopyAndPaste.spec.mjs:366 test: Paste multiple blocks into a link
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/LinksHTMLCopyAndPaste.spec.mjs:367 test: dynamic or multiline title

`../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/ListsHTMLCopyAndPaste.spec.mjs` Copy Chapter

category: portable
family: clipboard-paste / browser-engine
target: .tmp/slate-v2/packages/slate/test/clipboard-contract.ts; .tmp/slate-v2/packages/slate-dom/test/clipboard-boundary.test.ts; .tmp/slate-v2/playwright/integration/examples/paste-html.test.ts; .tmp/slate-v2/playwright/stress/generated-editing.test.ts

• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/ListsHTMLCopyAndPaste.spec.mjs:21 test: HTML Lists CopyAndPaste
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/ListsHTMLCopyAndPaste.spec.mjs:24 test: Copy + paste a list element
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/ListsHTMLCopyAndPaste.spec.mjs:25 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/ListsHTMLCopyAndPaste.spec.mjs:93 test: Copy + paste a Lexical nested list
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/ListsHTMLCopyAndPaste.spec.mjs:94 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/ListsHTMLCopyAndPaste.spec.mjs:129 test: Copy + paste (Nested List - directly nested ul)
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/ListsHTMLCopyAndPaste.spec.mjs:133 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/ListsHTMLCopyAndPaste.spec.mjs:217 test: Copy + paste (Nested List - li with non-list content plus ul child)
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/ListsHTMLCopyAndPaste.spec.mjs:221 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/ListsHTMLCopyAndPaste.spec.mjs:299 test: Copy + paste a checklist
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/ListsHTMLCopyAndPaste.spec.mjs:300 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/ListsHTMLCopyAndPaste.spec.mjs:372 test: Paste top level element in the middle of list
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/ListsHTMLCopyAndPaste.spec.mjs:377 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/ListsHTMLCopyAndPaste.spec.mjs:425 test: Copy + paste a nested divs in a list
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/ListsHTMLCopyAndPaste.spec.mjs:426 test: dynamic or multiline title

`../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/TablesHTMLCopyAndPaste.spec.mjs` Copy Chapter

category: portable
family: clipboard-paste / browser-engine
target: .tmp/slate-v2/packages/slate/test/clipboard-contract.ts; .tmp/slate-v2/packages/slate-dom/test/clipboard-boundary.test.ts; .tmp/slate-v2/playwright/integration/examples/paste-html.test.ts; .tmp/slate-v2/playwright/stress/generated-editing.test.ts

• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/TablesHTMLCopyAndPaste.spec.mjs:19 test: HTML Tables CopyAndPaste
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/TablesHTMLCopyAndPaste.spec.mjs:24 test: Copy + paste (Table - Google Docs)
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/TablesHTMLCopyAndPaste.spec.mjs:29 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/TablesHTMLCopyAndPaste.spec.mjs:31 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/TablesHTMLCopyAndPaste.spec.mjs:95 test: Copy + paste (Table - Google Docs with custom widths)
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/TablesHTMLCopyAndPaste.spec.mjs:100 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/TablesHTMLCopyAndPaste.spec.mjs:161 test: Copy + paste (Table - Quip)
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/TablesHTMLCopyAndPaste.spec.mjs:162 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/TablesHTMLCopyAndPaste.spec.mjs:233 test: Copy + paste (Table - Google Sheets)
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/TablesHTMLCopyAndPaste.spec.mjs:234 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/TablesHTMLCopyAndPaste.spec.mjs:306 test: Copy + paste - Merge Grids
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/TablesHTMLCopyAndPaste.spec.mjs:307 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/TablesHTMLCopyAndPaste.spec.mjs:308 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/TablesHTMLCopyAndPaste.spec.mjs:434 test: Copy + paste nested block and inline html in a table
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/TablesHTMLCopyAndPaste.spec.mjs:439 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/TablesHTMLCopyAndPaste.spec.mjs:441 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/TablesHTMLCopyAndPaste.spec.mjs:534 test: Copy + paste table with merged cells and unequal number of cells in rows
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/TablesHTMLCopyAndPaste.spec.mjs:539 test: dynamic or multiline title
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/TablesHTMLCopyAndPaste.spec.mjs:691 test: Copy + paste table with empty row
• ../lexical/packages/lexical-playground/__tests__/e2e/CopyAndPaste/html/TablesHTMLCopyAndPaste.spec.mjs:696 test: dynamic or multiline title