feat: Support tracking issue impact over time (#156)

[duncanleo]

Summary

Overhauls mrtdown-data into the canonical reviewed data repository for MRTDown, with typed packages, deterministic file-backed tooling, and a migrated append-only issue dataset.

What Changed

• Migrated canonical data into the new data/ layout:
  • static entities under data/{station,line,service,operator,town,landmark}
  • issues under data/issue/YYYY/MM/<issue_id>/
  • append-only evidence.ndjson and impact.ndjson per issue
• Introduced the monorepo package structure:
  • @mrtdown/core for schemas and shared period/state helpers
  • @mrtdown/fs for file-backed repositories and writers
  • @mrtdown/cli for creation, validation, manifest, listing, show, and repair tooling
  • @mrtdown/triage for LLM-assisted evidence triage and replay utilities
• Removed the old API/database runtime from this repo; runtime serving and Postgres import now belong in mrtdown-site.
• Added GitHub Pages publishing for generated manifests and downloadable data archives.
• Added Changesets/npm publishing workflow for shared packages.
• Added architecture docs describing the canonical-data vs runtime-data split and the two-repo mrtdown-data / mrtdown-site model.
• Replayed and normalized issue impact data, including repairs for empty impacts, degraded-service extraction, recurring maintenance periods, and legacy issue normalization.

Breaking Changes

• This repo no longer ships the old Hono/API/DuckDB runtime.
• Consumers should use the new packages and/or the generated GitHub Pages data artifacts instead of importing from the previous src/api, src/db, or legacy schema paths.

Review Notes

This is a large structural migration. The most important review areas are:

• package boundaries and exports
• canonical data layout compatibility with mrtdown-site
• CLI validation behavior
• generated manifest/archive workflow
• issue impact replay correctness

Validation

TODO before merge:

• npm ci
• npm run build
• npm run test
• npm run cli -- -- validate
• Confirm Pages artifact generation with npm run cli -- -- manifest and npm run cli -- -- pages-index

Fixes #156

[duncanleo]

@codex review

[chatgpt-codex-connector]

💡 Codex Review

mrtdown-data/packages/triage/src/util/ingestContent/index.ts

Line 20 in e29fd65

const DATA_DIR = resolve(import.meta.dirname, '../../../../data');

Point ingestContent to the repository data directory

ingestContent resolves DATA_DIR with four .. segments from packages/triage/src/util/ingestContent, which lands at <repo>/packages/data instead of <repo>/data; that directory does not exist in this repo, so the first repository read (via FileStore.listDir in triage flow) will throw ENOENT and break webhook ingestion. This is production-impacting because ingestViaWebhook imports and executes this code path for every incoming message.

---

mrtdown-data/packages/fs/src/repo/issue/IssueRepository.ts

Lines 177 to 180 in e29fd65

	'impact.scopeItems.serviceId',
	'impact.scopeItems.stationId',
	'impact.scopeItems.fromStationId',
	'impact.scopeItems.toStationId',

Query against actual impact event fields in issue search

The Fuse search keys target impact.scopeItems.*, but IssueRepository.get() stores impact data under impactEvents with event-specific fields (serviceScopes, entity.serviceId, etc.), so these clauses never match and searches by affected services/stations silently fail. This degrades FindIssuesTool matching and can cause triage to miss existing related issues.

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".