docs: remove stale internal guidance

Author: chenglou

DEVELOPMENT.md

@@ -35,13 +35,12 @@ bun install
 - `bun run pre-wrap-check` — compact batched browser oracle for `{ whiteSpace: 'pre-wrap' }`
 - `bun run keep-all-check` — compact batched browser oracle for `{ wordBreak: 'keep-all' }`, including mixed-script no-space canaries
 - `bun run symbol-check` — compact batched Chrome + Safari oracle for no-space symbol runs inside long words
-- `bun run letter-spacing-check` — compact batched browser oracle for `{ letterSpacing }`, using one posted-report probe per browser and covering narrow wraps, combining marks, bidi, CJK, emoji, digits, RTL punctuation, `pre-wrap`, and soft hyphens
+- `bun run letter-spacing-check` — compact batched Chrome + Safari oracle for `{ letterSpacing }`
 - `bun run letter-spacing-snapshot` — refresh `accuracy/letter-spacing.json` from the Chrome + Safari compact `{ letterSpacing }` oracle
 - `bun run probe-check` — smaller browser probe/diagnostic entrypoint
 - `bun run probe-check:safari`
-  On a first-break mismatch, probe output now includes a small break trace.
-  `sN:gM` means segment/grapheme position, `unit` is that unit's width, `fit` is the cumulative fitted width from the current line start, and `[ours]` / `[browser]` mark the competing break boundaries.
-  For Safari URL/query misses or other extractor-sensitive cases, cross-check `--method=span` before changing the engine.
+
+Probe output includes a break trace on first-break mismatches. `sN:gM` is a segment/grapheme position; `[ours]` and `[browser]` mark the competing boundaries. For extractor-sensitive Safari cases, cross-check `--method=span` before changing the engine.
 
 ### Corpus Tooling
 
@@ -61,20 +60,12 @@ bun install
 
 ## Useful Pages
 
-The ones worth keeping in your muscle memory:
-
-- `/demos/index`
-- `/demos/bubbles`
-- `/demos/dynamic-layout`
-- `/demos/editorial-engine`
-- `/demos/justification-comparison`
-- `/demos/markdown-chat`
-- `/demos/rich-note`
-- `/accuracy`
-- `/benchmark`
-- `/corpus`
+- `/demos/index` — index of the public demos
+- `/accuracy` — browser sweep and per-line diagnostics
+- `/benchmark` — performance comparisons
+- `/corpus` — long-form corpus diagnostics
 
-## Current Sources Of Truth
+## Current Dashboards And Snapshots
 
 Use these for the current checked-in picture:
 
@@ -84,38 +75,16 @@ Use these for the current checked-in picture:
 - [benchmarks/chrome.json](benchmarks/chrome.json), [benchmarks/safari.json](benchmarks/safari.json) — raw benchmark snapshots
 - [corpora/dashboard.json](corpora/dashboard.json) — machine-readable corpus dashboard
 - [corpora/chrome-step10.json](corpora/chrome-step10.json), [corpora/safari-step10.json](corpora/safari-step10.json) — checked-in browser `step=10` corpus sweep snapshots
-- [PLATFORM_BUGS.md](PLATFORM_BUGS.md) — current browser/OS issue and workaround ledger
-- [RESEARCH.md](RESEARCH.md) — the exploration log and the durable conclusions behind the current model
+
+[PLATFORM_BUGS.md](PLATFORM_BUGS.md) is the current browser/OS issue and workaround ledger. [RESEARCH.md](RESEARCH.md) keeps durable findings and rejected approaches; it is not a source for current counts or tracker status.
 
 ## Deep Profiling
 
-For one-off performance and memory work, start in a real browser.
-
-Preferred loop:
-
-1. Start the normal page server with `bun start`.
-2. Launch an isolated Chrome with:
-   - `--remote-debugging-port=9222`
-   - a throwaway `--user-data-dir`
-   - background throttling disabled if the run is interactive
-3. Connect over Chrome DevTools or CDP.
-4. Use a tiny dedicated repro page before profiling the full benchmark page.
-5. Ask the questions in this order:
-   - Is this a benchmark regression?
-   - Where is the CPU time going?
-   - Is this allocation churn?
-   - Is anything still retained after GC?
-
-Use the right tool for each question:
-
-- Throughput / regression:
-  - [pages/benchmark.ts](pages/benchmark.ts)
-  - or a tiny dedicated stress page when the issue is narrower than the whole benchmark harness
-- CPU hotspots:
-  - Chrome CPU profiler or performance trace
-- Allocation churn:
-  - Chrome heap sampling during the workload
-- Retained memory:
-  - force GC, take a before heapsnapshot, run the workload, force GC again, take an after heapsnapshot, and diff what survives
-
-A pure Bun/Node microbenchmark is still useful for cheap hypothesis checks, but it is not the final answer when the question is browser behavior.
+For one-off performance and memory work, start with `bun start` and an isolated, foreground Chrome using a throwaway profile. Reproduce the issue on [pages/benchmark.ts](pages/benchmark.ts), or on a smaller dedicated page when the benchmark is too broad.
+
+- Use the benchmark for throughput regressions.
+- Use a CPU profile or performance trace for hotspots.
+- Use heap sampling for allocation churn.
+- Diff forced-GC heap snapshots for retained memory.
+
+Bun/Node microbenchmarks are useful for cheap hypotheses, but browser behavior needs browser evidence.