Conversation
Latest implementation and proposed next step: incremental global-data preparationPushed 3fcbc14 with all previously uncommitted changes:
The complete local Remaining performance problemPage-owned Markdown outputs have removed the collection-wide raw-write amplification. However, Proposed division of responsibilityKeep existing fingerprints and This proposal is not implemented in the current PR. Oro portion
For a paragraph edit, Oro may reconstruct Runtime navigation as well as search/LLM projections. The existing fingerprints will establish that navigation is unchanged and only search/exports invalidate their subscribers. The source event independently selects the edited page and its raw output. DOMStack portionProvide backward-compatible, explicit application state and batched input-change context to global data. The context must derive from the existing watch/dependency machinery rather than a second dependency graph. Distinguish reset from conservative page upserts/removals; raw filesystem events can accompany the semantic batch but cannot be the sole correctness contract. State must survive DOMStack’s fresh per-build workers. A minimal first version can retain structured-cloneable state in the watch session, pass it into the worker, and commit a candidate only after the relevant build succeeds. Producer-code changes, incompatible state, or uncertain dependencies reset it. Existing return values remain public global data; private producer state is separate. Explicit non-goals
Fingerprint all published top-level values as today. If fingerprinting becomes a measured bottleneck, optimize the existing tracker rather than adding a competing application system. A fingerprint establishes equality but cannot replace cached rendered search text. Validation and limitsInstrument source initialization, Markdown reads/search renders, projection work, state transfer, fingerprinting, and output work separately. Prove one ordinary body edit performs one index/search render, then compare incremental data/output with clean builds after H1 changes, overrides, adds/deletes/moves, membership/alias changes, shared vars/settings/helper edits, batched events, and failed-build recovery. This does not initially eliminate all-page source initialization, state cloning, serialization, or fingerprint traversal. The first target is repeated full-corpus Markdown rendering. Ingestion stays manual and separate from builds. Framework work is tracked in bcomnes/domstack#325, which links back to this application plan. Neither the incremental state API nor the Oro index optimization is implemented yet. |
|
Superseded by the requested two-PR stack:
Merge #2 first, then retarget/rebase #3 onto master as needed. Both replacement PRs are drafts and passed their full local validation suites independently against their parents (Brave used for local browser tests). The original branch is preserved and pushed at 515761e, including the formerly uncommitted index work. The final stack tree and that checkpoint have the same Git tree ID: 3f6e1ea523fca7c4a917a5dd16b4d2d112cc2076. No combined work was lost. Closing this combined PR only to direct review to the two slices; retaining this branch and discussion as history. The incremental-data plan above is now implemented in #3 using DOMStack beta.7. |
Summary
Follow up on the DOMStack migration with native page-owned exports, narrower data boundaries, checked layout contracts, TypeScript-only tooling, and targeted client improvements. Preserve the static architecture, branding, article Markdown, existing HTML/raw routes, heading anchors, and upstream ownership policies. Retire unused public navigation JSON endpoints intentionally.
DOMStack data, outputs, and types
@domstack/staticto12.0.0-beta.6and use nativepageOutputsfrom the shared docs/spec layouts. Each page owns its raw Markdown file; six collection-wide source templates are removed. No framework patch or patch-package dependency..txtexports. Watch mode skips unchanged raw writes and cleans up renamed/deleted outputs.src/globals/global.data.ts; move global vars alongside it. Global search preparation still processes all docs: the page-output improvement fixes write amplification, not that computation.index.jsonexports; retain search JSON used by the browser. Content audits derive expected raw outputs from committed Markdown metadata rather than removed JSON catalogs.TypeScript-only tooling
Clients, assets, and workflows
Latest title and redirect changes
redirectFrommetadata for the two existing path aliases, with validated collection data and a typed generated-pages factory. Redirects retain the full root layout, canonical metadata, query/fragment handling, and no-JavaScript fallback.Review notes
All documentation article bodies remain unchanged. Frontmatter now omits 585 redundant titles and records the two existing path aliases through redirectFrom. No collection-specific layout wrappers or per-document TypeScript companions are introduced.
Ingestion remains manual and separate from rendering and CI. No upstream refresh or production deployment was performed. Tests focus on changed behavior and port parity rather than broad coverage expansion.
Suggested review order: shared data and layouts; page outputs and artifact templates; layout registry and vars checks; ingestion/audit ports; clients and workflow/documentation changes.
Validation
The complete
npm run checkgate passed locally after the final registry integration:Focused verification:
.txtoutput.Earlier validation also covered Python/TypeScript ingestion parity and computed styles on nine routes at three viewport widths.
Browser caveat: local browser validation uses installed Brave via
ORO_BROWSER_EXECUTABLE; CI remains configured to install Playwright Chromium. Local validation passing does not imply the newly triggered CI run has finished.Deployment
Review and merge through the normal Pages workflow. No upstream ingestion is required to build this branch.