Feature plan: Step 1 · Step 2 · Step 3 · Step 4

Debug mode: enabled

Completion Contract

Ordinary Platform Docs discovery/direct URLs lead to readable supported pipe tables, safe cell destinations and keyboard/phone scrolling in PHP and copied full/shared static releases. Unsupported blocks retain escaped source and adjacent content. Failed publication retains the active release; restoration/retry succeeds. Require focused regressions, refreshed corpus/classification evidence, rendered theme checks and accurate runbook support boundaries before handoff. Live deployment/external-host acceptance is outside scope; report it pending, never inferred from local package checks.

Key Risks

• High risk: wrong splitting changes meaning. Validate escaped/code pipes, width mismatches and block boundaries in Stages 1–2; ambiguous blocks fall back whole before delivery work.

• High risk: cell links/HTML bypass safety. Exercise canonical escaping/link boundaries in Stage 2; no parallel inline parser or image fetch.

• High risk: overflow hides columns or failed builds replace usable readers. Validate real keyboard/390px scrolling and injected failure/retry in Stages 3–4; block release on failure.

Stage 1 — Supported tables in the ordinary reader

• Goal: render well-formed standalone tables.

• Dependencies: Step 3 approval and planning commit.

• Expected changes: extend canonical block recognition for header/delimiter/body, optional outer pipes, empty cells and alignment; semantic column headers and existing inline formatting.

• Verification approach: focused renderer/reader cases for two-plus columns, header-only tables, alignment and ordinary guide URLs.

• Risks or open questions: false prose recognition; test prose/fences beside tables early, require matching header/delimiter widths.

• Canonical components/API contracts touched: PublicMarkdownRenderer; existing render signature and PlatformDocsController entry unchanged.

Stage 2 — Boundary and safety completion

• Goal: preserve content under ambiguous/adversarial input.

• Dependencies: Stage 1 verified and committed.

• Expected changes: escaped pipes, existing single-backtick code spans, exact-width rows and whole-block source fallback; exclude multiline/merged/nested/list/quote table extensions.

• Verification approach: uneven/empty rows, optional delimiters, unmatched code, escape parity, adjacent prose, HTML, hostile URLs, fragments, traversal/symlinks and image alternatives; compare source preservation.

• Risks or open questions: lost cells or unsafe destinations; failing boundary fixtures block Stage 3, retain escaped source where unsupported.

• Canonical components/API contracts touched: renderer and existing PlatformDocsCatalog link policy; page/security regressions.

Stage 3 — Accessible reader integration

• Goal: access every column without page overflow.

• Dependencies: Stage 2 verified and committed.

• Expected changes: reuse existing table/scroll/focus CSS; preserve alignment against default cell styles and accessible scroll regions, without explanatory copy.

• Verification approach: JavaScript-off desktop/390px reader, actual Tab/arrow scrolling, visible focus, safe cell-link destination and surrounding headings/procedure/code behavior.

• Risks or open questions: CSS overrides or trapped focus; inspect real loaded output before proceeding.

• Canonical components/API contracts touched: canonical reader markup, platform_docs.css, existing browser harness.

Stage 4 — Portable publication and recovery

• Goal: deliver matching tables through normal releases.

• Dependencies: Stage 3 verified and committed.

• Expected changes: update existing Docs static assertions and copied-package evidence for supported tables/fallbacks.

• Verification approach: complete copied application, actual full/shared publication, dynamic/static reader and cell-link parity, refresh/deleted-reader behavior; inject renderer failure, confirm dynamic failure response and retained active release, restore and retry. Keep docs stable during snapshot tests.

• Risks or open questions: stale assets or partial activation; verify normal publication/recovery paths, no production activation.

• Canonical components/API contracts touched: existing controller/static builder/publication contracts and PlatformDocsStaticTest.

Stage 5 — Corpus and theme acceptance

• Goal: close the approved reader slice with evidence.

• Dependencies: Stage 4 verified and committed.

• Expected changes: corpus report, classification of all 66 measured table documents as supported/fallback with reasons, runbook boundary update and cycle/ledger closeout.

• Verification approach: metrics fixture, zero-error refreshed renders, focused Docs/catalog/static regressions; desktop/390px dynamic/static default/Word97/Chicago/Midnight screenshots, overflow/focus/alignment/link checks. Review representative tables visually; record all unreviewed outcomes and failures.

• Risks or open questions: zero errors conceal lost structure; classify source examples and inspect rendered outcomes, not counts alone.

• Canonical components/API contracts touched: metrics/probe, existing theme styles, runbook and cycle artifacts; no navigation/icon changes.

Execution and study checkpoint

Each stage targets ≤1 hour; split oversized work before starting it, return to Step 2 for changed scope. After approval create a fresh extension branch from the synchronized audit descendant, organize this cycle's plans/references, commit approved Steps 1–3/debug log first, then one verified stage/summary commit before the next stage. Existing metrics/ledger evidence belongs in authorized stage work, outside the narrow planning commit. Preserve unrelated edits and all recovery storage; no todo.txt changes. No dependency additions/upgrades/copied code or schema changes.

Steps 1–3 explicitly approved; implementation authorized. Study v3/markdown_renderer_extension, v1/R1/P2, same baseline/exposed single rater; 0.65 total reaffirmed with verification/recovery included. Checkpoint/diagnostics. No implementation or accepted outcome.