Portable page architecture
Fictional sample. Every metric, status, organization, and decision on this page exists only to demonstrate the report engine; replace it with verified project evidence before use.
This starter records one system decision in enough detail for implementation and later reversal. It keeps the trust boundary visible instead of hiding it in framework code.
System boundary
Decision
Use one declarative compilation path
Keep Markdown, metadata, confined partials, and local assets as the public source. Compile them into static output using package-owned renderers and a bounded event-delegated runtime.
| Force | Consequence |
|---|---|
| Offline portability | No remote runtime or author-time network fetch |
| Agent ergonomics | No JSX, CSS, or JavaScript required |
| Security review | Data-only directives with explicit constraints |
| Deterministic output | Package versions and local source determine bytes |
Runtime flow
Alternatives and consequences
Alternatives considered
One registry, model, renderer, and bounded runtime keep every supported page on the same contract.
Maximum freedom, but every page owns framework setup, security review, accessibility, and packaging.
Fast visual editing, but it introduces a service dependency and weakens offline portability.
Positive
Authors provide data and semantic intent; the package owns browser behavior.
Trade-off
New interaction classes require a package release instead of arbitrary author JavaScript.
Guardrail
All filesystem references are confined before reads and all output works locally.
Rollout
Adopt the decision
- Replace the sample decision and evidence in the declarative source.
- Build semantic output through the shared compiler.
- Open the artifact through
file://at desktop and mobile widths. - Revisit the decision when a verified requirement no longer fits the boundary.
