Slate v2 ClawSweeper Corpus Recluster Ralplan

Verdict

Run ClawSweeper on the full live issue corpus, but do not brute-force 630 issues one by one.

The best shape is:

refresh gitcrawl mirror
+ rebuild machine clusters
+ create a human architecture cluster overlay
+ process clusters by value/risk
+ append one fork-local dossier section per reviewed issue
+ sync only exact claims into PR docs

Machine clusters are candidate discovery. Human architecture clusters are the truth we use for Slate v2 planning.

Intent And Boundary

• intent: convert live Slate issue history into fork-local v2 issue accounting without commenting on upstream issues.
• desired outcome: every important live issue family has a reviewed ClawSweeper decision, and every reviewed issue has a section in docs/slate-v2/ledgers/fork-issue-dossier.md.
• in scope: live gitcrawl mirror, live open issue ledger, gitcrawl cluster rebuild, human re-clustering, fork issue dossier, PR issue claim references.
• non-goals: no upstream GitHub comments, labels, closes, or Fixes #... claims without exact repro proof.
• decision boundary: ClawSweeper may classify, re-cluster, and document. It may not turn architecture pressure into exact closure.

Current Corpus Facts

From docs/slate-issues/gitcrawl-rebuild-report.md:

The current fork dossier has 10 issue sections. That means the next work is not “finish the document polish.” The next work is the corpus pipeline.

Decision Brief

Principles:

• Use live open issues as current truth.
• Ignore old v2 ledger notes as evidence unless the user explicitly names them.
• Treat gitcrawl clusters as discovery, not final taxonomy.
• Route issues by raw Slate architecture owner, not product wishlists.
• Write fork-local issue sections instead of upstream comments.

Decision drivers:

• 589 / 617 gitcrawl clusters are singletons, so machine clustering alone is too conservative.
• Live gitcrawl output is enough to rebuild the corpus; the old v2 ledger does not need to participate in the pass.
• The fork needs a full PR/audit story, not official upstream issue actions.

Chosen option:

• Re-cluster into human architecture families on top of gitcrawl output, then process by family and issue confidence.

Rejected options:

• Brute-force every issue in order: too slow and produces noisy prose.
• Trust only gitcrawl clusters: misses singleton families and splits one architecture pressure across many singletons.
• Require non-live legacy evidence for every row: stale overhead; it slows the live corpus pass without improving current truth.
• Write upstream comments: wrong for a fork.

Re-Clustering Strategy

Use three layers.

Layer 1: Fresh machine corpus

Refresh and rebuild:

GITHUB_TOKEN="$(gh auth token)" gitcrawl refresh ianstormtaylor/slate --include-comments --state open --json
gitcrawl cluster ianstormtaylor/slate --threshold 0.80 --min-size 1 --max-cluster-size 40 --k 16 --cross-kind-threshold 0.93 --json
gitcrawl clusters ianstormtaylor/slate --json

Store outputs under .tmp/gitcrawl/ with timestamped filenames and summarize them into docs/slate-issues/gitcrawl-rebuild-report.md.

Use gitcrawl clusters and cluster-detail for multi-member clusters. Use gitcrawl neighbors and gitcrawl search for singleton expansion.

Layer 2: Human architecture families

Create/update:

docs/slate-issues/gitcrawl-recluster-map.md

Each human family must have:

• family id
• architecture owner bucket
• source gitcrawl cluster ids
• singleton issue refs pulled in by search/neighbors
• direct PR-linked refs
• decision: keep, docs, stale, pr-only, split, or needs-repro
• why it is one family
• why excluded neighbors are not in the family

Start from these known families:

• DOM point/path/selection crashes
• Android/mobile IME and beforeinput
• inline/void boundary selection
• history and undo selection state
• React external-store/focus/subscription runtime
• decoration/projection/caret jumps
• clipboard/HTML/fragment serialization
• large-document performance and virtualization tradeoffs
• docs/examples/support noise
• stale browser-support rows

Layer 3: ClawSweeper issue sections

Append reviewed issues to:

docs/slate-v2/ledgers/fork-issue-dossier.md

Use one section per issue with the ClawSweeper shape:

Status
Bucket
Confidence
Issue summary
Evidence
Decision
PR-description text

Do not duplicate the long form in pr-description.md.

Batch Order

Batch 0: Rebuild and sanity check

Goal:

• prove the live mirror is fresh
• regenerate machine clusters
• record drift from the last report

Outputs:

• refreshed .tmp/gitcrawl/*
• updated docs/slate-issues/gitcrawl-rebuild-report.md
• updated docs/slate-issues/gitcrawl-clusters.md
• new/updated docs/slate-issues/gitcrawl-recluster-map.md

Gate:

• counts reconcile: live issues, open PRs, total threads, cluster count, singleton count, multi-member count.

Batch 1: High-signal multi-member clusters

Process keep clusters before singleton noise:

• cluster 1: DOM point resolution crashes
• cluster 5: inline boundary cursor movement
• cluster 6: history set_selection errors
• cluster 7: ReactEditor focus after programmatic change
• cluster 9: Android mark-toggle keyboard dismissal
• cluster 10: async decoration caret jump
• cluster 11: Android empty-node voice input duplication
• cluster 12: mobile inline void selection keyboard
• cluster 13: Android IME empty-node composition
• cluster 14: refocus autoscroll

For each cluster:

• run gitcrawl cluster-detail
• run gitcrawl neighbors on representative and suspicious members
• split mixed rows
• append issue dossier sections
• sync ledger status only when the claim changes

Batch 2: Finish weak and split clusters

Immediate target:

• finish cluster 3 by triaging #3777

Then process:

• weak clusters where one machine family hides multiple runtime owners
• PR-linked clusters where the PR may change claim posture
• docs/stale clusters that should be excluded with reasons

Gate:

• no machine cluster marked keep remains unreviewed or unassigned to a human family.

Batch 3: Singleton expansion by architecture family

Because 589 singleton clusters exist, search by human family, not by issue number.

Use this loop:

gitcrawl search ianstormtaylor/slate --query "<family phrase>" --mode hybrid --limit 50 --json
gitcrawl search issues "<family phrase>" -R ianstormtaylor/slate --state open --json number,title,state,url,updatedAt,labels --limit 50
gitcrawl neighbors ianstormtaylor/slate --number <representative> --limit 20 --json

Suggested family phrases:

• Cannot resolve a Slate point from DOM point
• Cannot resolve a Slate node from DOM node
• Android composition beforeinput
• Samsung keyboard Firefox Android
• inline void selection keyboard
• placeholder composition
• ReactEditor focus parent state
• useSelected stale path
• decorate async caret jump
• history set_selection undo
• copy paste inline void
• large document paste cut performance

Gate:

• every high-signal singleton either joins a human family, becomes needs-repro, or is explicitly skipped with a reason.

Batch 4: Docs/examples/stale/noise sweep

Goal:

• remove noise from core architecture accounting
• keep useful docs/example gaps separate

Outputs:

• dossier sections only for rows that need future PR explanation
• ledger updates for triage-closed/stale/docs outcomes when needed

Gate:

• docs/example/support rows do not pollute raw Slate runtime plans.

Batch 5: Exact claim audit

Goal:

• verify whether any reviewed issue deserves fixes-claimed
• keep every other issue as improves-claimed, cluster-synced, issue-reviewed, not-claimed, triage-closed, or needs-repro

Rules:

• exact closure requires exact repro proof
• mobile/IME claims require device/browser proof matching the report
• performance claims require benchmark evidence
• DOM selection claims require browser proof, not only unit tests

Outputs:

• updated docs/slate-v2/ledgers/issue-coverage-matrix.md
• updated docs/slate-v2/references/pr-description.md
• updated docs/slate-v2/ledgers/fork-issue-dossier.md

Confidence Score

Total: 0.92

Verdict: ready for user review. Execution should start with Batch 0, then Batch

Required Outputs

• docs/slate-issues/gitcrawl-rebuild-report.md
• docs/slate-issues/gitcrawl-clusters.md
• docs/slate-issues/gitcrawl-recluster-map.md
• docs/slate-issues/gitcrawl-live-open-ledger.md
• docs/slate-v2/ledgers/fork-issue-dossier.md
• docs/slate-v2/ledgers/issue-coverage-matrix.md
• docs/slate-v2/references/pr-description.md
• session completion file under .tmp/completion-checks/

Completion Gates

The corpus/re-clustering lane is complete only when:

• fresh gitcrawl refresh and cluster outputs are recorded
• every keep multi-member cluster has a human-family decision
• every weak cluster is split or marked needs-human
• every PR-linked issue cluster is reviewed
• high-signal singleton searches are processed by architecture family
• every reviewed issue has a fork dossier section
• every exact Fixes #... claim has matching proof
• pr-description.md includes only short claim/count summaries
• no upstream GitHub issue comment, label, or close was made
• bun run completion-check passes with this lane marked done

Next Ralph Owner

Start with Batch 0:

current_pass: clawsweeper-recluster-batch-0
current_pass_skill: .agents/skills/clawsweeper/SKILL.md
current_pass_owner: docs/slate-issues + docs/slate-v2/ledgers
current_pass_scope: refresh gitcrawl, rebuild clusters, create recluster map skeleton

Then move to Batch 1 high-signal multi-member clusters.

Execution Ledger