FACTUAL ACTIVITY RECORD · An activity record based on work that took place
Publishing activity history as list and detail pages
Implementing seven records as public-only data with bilingual reading paths and navigation
Purpose
The initial activity records existed as Japanese and English editorial candidates, but visitors did not yet have public pages that led from the home page to a list, each full record, and corresponding locales.
The approved copy needed to become typed public-only data with stable URLs, metadata, navigation, responsive presentation, and keyboard operation, without exposing internal evidence on the public surface.
Implementation
Seven records were placed in typed public-only data, each with Japanese and English slugs, titles, summaries, periods, formats, bodies, and status. Required locale fields, inventory count, and duplicate slugs were checked during the build, while internal source references and clearance data remained outside public data.
One list and seven details were generated for each locale. The list presents date, summary, status, and a detail path in one column; each detail places exactly one return path before its title and body. A record that was not adopted retains its status and explanation rather than appearing adopted.
- Set canonical, alternate-locale, default-locale, and description metadata for every localized list and detail.
- Add a utility link from the home-page work item to the list in the same locale.
- Give activity pages primary navigation and a mobile menu returning to same-locale home sections.
- Keep the Privacy Policy and Terms of Use simple and scriptless, without extending activity-page menu behavior to them.
The first implementation check found mismatches with the approved design in activity-page navigation, the number of desktop list columns, and the return path at the start of details. The design was left unchanged: the list was fixed to one column, the return path moved to the beginning of the hero, and accessible navigation was added only to activity pages.
An independent expected-output contract fixed all 22 public content outputs by digest and checked navigation and locale targets across 16 activity outputs, return-path count and DOM order across 14 details, metadata, sitemap, unpublished-data leakage, and existing legal-page boundaries. Desktop and mobile checks also covered layout, overflow, focus, Escape, and 44-pixel targets.
Public data used one bilingual type and generated list and detail paths through the same helper. Internal sources and clearance metadata were not part of this public type.
Rendering diagram…
What was confirmed
Verification results
One list and seven details per locale produced 16 activity pages, with same-locale paths from home to list, detail, and back to list.
Stable URLs, canonical and locale relationships, metadata, sitemap entries, non-adoption status, and the AI-persona disclosure matched the public data.
Design mismatches were corrected through activity-page navigation, a one-column list, and a return path at the beginning of each detail; desktop and mobile rechecks passed for keyboard behavior and horizontal overflow.
At the cutoff, all 22 content URLs were reachable, and generated output, bilingual paths, metadata, sitemap, and redirects matched the expected contract. No failure remained, and the result was applied to the public surface.
Basis for completion
The work was complete when seven activity records were generated from public-only data into bilingual lists and details, aligned with design, navigation, accessibility, metadata, and public boundaries, and all 22 content URLs had verified reachability and output equality.