Stage 1 Methodology Page

The Stage 1 Methodology Page publishes the current Methodology 2.0.0 at /methodology/ and preserves the immutable v1 route at /methodology/1.0.0/. The version route also supports /methodology/2.0.0/ and any other validated Methodology version present in the release. It lets readers inspect how public labels and evidence judgments are defined, while each Entry can point to the exact rules used for that record. This page is for maintainers, technical users, and coding agents changing Methodology projection, routing, anchors, canonical metadata, or public rulebook presentation.

Purpose and Ownership

The feature turns one validated canonical Methodology record into a complete public rulebook. It owns:

  • Projection of canonical Methodology content into ordered display records, labels, scores, links, and safe HTML.
  • The exact H1, H2, and H3 hierarchy of the public rulebook.
  • Stable section IDs and the ordered Jump To index.
  • The open reading layout, ruled definition tables, compact version strip, and responsive mobile transformations.
  • Static current and immutable version routes for every validated Methodology version, including the v2 current route and preserved v1 route.
  • Page-level checks that every Jump To destination belongs to the rendered anchor contract.

It does not own:

  • Methodology content, definitions, version identity, or effective date. Canonical Records owns those values.
  • Canonical route paths and absolute URLs. Route generation and Release Construction own them.
  • Entry assessment data or the Methodology version assigned to an Entry.
  • Shared Header, Footer, focus tokens, typography, colors, or generic table behavior.
  • Runtime fetching, client recovery, analytics, or logging.

Inputs and Output Contract

The feature accepts one ResolvedMethodology from the application release boundary. That value contains the validated canonical Methodology record plus its current and version-specific absolute URLs.

The v1 createMethodologyPageViewModel maps exhaustive controlled values through their approved public labels and preserves their canonical order. The v2 MethodologyV2Page validates and renders the current Entry v2 content contract, including assessment rationales, removal lifecycle, the six Entry v2 fields, and the v2 date definitions. Both projections render Methodology Markdown through the shared safe renderer and receive route URLs from the resolved release; neither rewrites definitions or infers missing content.

MethodologyPage.astro selects the v1 or v2 renderer from the validated Methodology record. The current route and each immutable version route render the selected record's substantive content, while the surrounding layout supplies the route-specific canonical link.

Static Route Flow

  1. Each thin Astro route loads the configured application release.
  2. Development and test builds use fixed non-production metadata; production uses the persisted release descriptor.
  3. Release construction selects the highest validated semantic version as current and retains every validated version in ResolvedMethodology.versions.
  4. /methodology/ renders the selected current record and canonicalizes to the current URL; the dynamic version route generates one static path per retained version and canonicalizes to that version's URL.
  5. MethodologyPage.astro dispatches v1 content to the established projection and v2 content to the Entry v2 rulebook renderer.
  6. Astro writes each complete rulebook into static HTML. The browser does not fetch Methodology content at runtime.

An unregistered version is absent from getStaticPaths() and falls through to the generic static 404 page. The release must retain both 1.0.0 and 2.0.0 when both records are present; preserving the v1 route does not make it the current route.

Rulebook Structure

The v1 page has one H1, Methodology. Its main sections appear in this order:

  1. Inclusion Rule.
  2. Jump To.
  3. Inclusion Standard.
  4. Claim Appraisal.
  5. Public Labels.
  6. Entry Fields.
  7. Sources and Evidence Types.
  8. Dates and Evidence Monitoring.
  9. Topic Trails and Domains.
  10. Entry Titles.
  11. Versioning.

Canonical structured fields own lists, examples, definitions, and table rows. Markdown leaves supply prose inside that structure; they cannot introduce competing headings, lists, or tables.

The v2 page has one H1, VyDex Entry v2 Methodology, and uses this main section order: Inclusion Rule, Jump To, Claim Appraisal, Public Labels, Entry v2 Fields, Sources and Evidence Types, Dates and Evidence Monitoring, Topic Trails and Domains, and Versioning. It intentionally removes the v1 Review Status, Entry State, Frontier Delta, Significance, and Caveats tables from the current public contract.

The version strip displays the selected public version, exact effective date, version type, and the rule that Entry pages link to the Methodology version used by the record. The current v2 strip links to /methodology/; each immutable version page links to the current route and keeps its own absolute self-canonical URL.

Stable Anchors and Entry Help Links

Each renderer owns its visible section fragments and Jump To destinations. The v1 projection retains its established anchors; the v2 renderer uses explicit v2-* section IDs. Entry pages link to the resolved immutable Methodology route as provenance; they do not hardcode a version or reconstruct Methodology anchors.

The Entry Page exposes one provenance link to the exact Methodology version used by its snapshot. Domain values, status rationales, and Topic Trail names are rendered from the Entry or resolved relationships; they are not converted into Methodology help links. Topic Trail names retain their links to the generated Stage 1 Topic Trail pages.

User-Facing Behavior

Methodology is the active Header destination on the current and every immutable Methodology route. Latest continues to link to /#latest.

The page uses open reading sections rather than a card around every section. Prose stays near the shared reading measure, while indexes and definition tables can use the wider page grid. Public labels remain visible in normal flow without tabs, accordions, tooltips, or a sticky sidebar.

Essential tables use real column headers. Each body cell also carries its column label so mobile layouts can convert rows into stacked ruled records without horizontal scrolling. Evidence Strength scores remain ordinary table data rather than ratings or progress indicators.

Anchor links use the global visible focus treatment. Anchored sections include scroll spacing so direct navigation does not place headings tightly against the viewport edge.

Failure Behavior

Canonical validation and release construction block the build when the Methodology record, effective date, named content sections, or exhaustive Evidence Type definitions are incomplete.

The page projection also rejects duplicate section IDs or a Jump To destination absent from the declared rendered-section contract. Browser tests verify that the declared IDs are present in the final HTML on both routes. Failures use normal thrown build errors and test output; the feature adds no recovery UI or logging layer.

Internal Edge Cases

  • A current route renders v2 2.0.0; an immutable route renders the exact selected version, so v1 and v2 routes intentionally have different content contracts.
  • The canonical record may contain safe emphasis, links, or inline code across multiple paragraphs. The shared Methodology renderer escapes HTML and rejects unsupported structures or unsafe URLs.
  • Claim Status rows use text to name the UI treatment. Failed / Retracted may use the approved red accent, but no row relies on color alone.
  • The v2 rulebook renders assessment rationales and removal lifecycle from the v2 content contract; it does not synthesize v1 Review Status or Entry State sections.
  • Domain, Evidence Type, Source Role, status, state, and version rows follow exhaustive domain-owned ordering rather than object enumeration chosen by the component; v2 omits the v1-only state and review rows.
  • Browser Find reaches every core definition because the page does not defer or hide content.

Cross-System Edge Cases

  • Release Construction supplies the selected Methodology, all retained versions, and their canonical URLs. The page must not parse authoring files or construct route URLs itself.
  • Stage 1 Entry Page uses the resolved immutable Methodology URL as provenance. It must not hardcode 1.0.0 or 2.0.0 into Entry links.
  • Stage 1 Site Shell derives the active Methodology state from the pathname and owns document order.
  • Frontier Atlas owns responsive table behavior, typography, colors, focus, and page measurements. The Methodology feature owns only their rulebook composition.
  • Static Application Foundation owns the build mode, application release boundary, canonical-link layout interface, and browser-test harness.
  • The current route may change in a later Methodology release, but an immutable version route must continue to render the content and canonical URL for that exact version.

Invariants

  • Each rendered version comes from one canonical Methodology record; the current route selects the highest validated semantic version.
  • Every retained version has its own static route and version-specific canonical URL.
  • The exact-version route canonicalizes to itself, while /methodology/ canonicalizes to the selected current version.
  • Version-strip links stay on the current origin while canonical metadata remains absolute.
  • Entry provenance links use the exact Methodology version assigned to the Entry.
  • Every Jump To link resolves to one visible section with a stable explicit ID.
  • Every public definition for the selected Methodology contract remains visible in normal document flow.
  • Evidence Strength is support for the stated claim, not importance, confidence, probability, or rank.
  • The page contains exactly one H1 and preserves the approved H2 and H3 hierarchy.
  • Core content remains readable without browser JavaScript.
  • Rendering performs no runtime fetching, logging, telemetry, or persistent writes.

Implementation Landmarks

  • src/features/methodology-page/ — Version-specific Methodology projections, page composition, and feature-owned responsive styles.
  • src/pages/methodology/ — Thin current and immutable Astro routes.
  • src/shared/methodology-navigation/ — Stable section IDs and immutable fragment-link construction.
  • src/shared/public-navigation/ — Same-site navigation projection for the immutable version link.
  • src/shared/canonical-markdown/ — Safe Markdown rendering shared by canonical presentation profiles.
  • src/layouts/FoundationLayout.astro — Optional canonical-link output and shared document shell.
  • tests/features/ and tests/browser/methodology-page.spec.ts — Projection, route, anchor, responsive, no-JavaScript, and accessibility coverage.

Before Changing the Methodology Page

Check:

  • Whether every displayed definition still comes from the validated canonical record.
  • Whether current and immutable routes still dispatch the correct v1 or v2 renderer for the selected canonical record.
  • Whether each route receives the correct self-canonical URL and the current route selects the highest validated version.
  • Whether every declared Jump To fragment remains present in the renderer that owns it.
  • Whether Entry provenance links still use the resolved immutable version URL while record values keep their own behavior.
  • Whether exhaustive controlled rows retain canonical order, labels, and scores.
  • Whether mobile tables retain every column label without horizontal scrolling.
  • Whether headings, focus, scroll spacing, no-JavaScript reading, and Browser Find behavior remain accessible.
  • Whether tests cover v1 compatibility, v2 content, per-version route identity, missing targets, unknown versions, and the absence of runtime fetching.

Read Canonical Records before changing Methodology content or validation, and Release Construction before changing resolved URLs or release selection.