Files
paper-atlas/docs/research-runtime.md
T
codex-bot f9f4d263af
Metadata integrity checks / metadata (push) Successful in 1m48s
Expose independent event keys in integrated coverage reports
2026-11-08 23:17:55 +08:00

3.2 KiB

Integrated research runtime

This branch composes the independently reviewed identity guards (PR25), incremental coverage (PR27), joint-edition refresh guard (PR29), event identity (PR30), and optional annotation support (PR28). It starts from main 1b81d1a and preserves their commits; it is an explicit integration dependency, not evidence that those PRs have merged. Users merge through Gitea manually. Review this combined diff against main, including its conflict resolutions, before using it as the maintained runtime.

The shared Store preserves stable source/identifier anchors before title matching, rejects ambiguous unanchored matches, resolves pinned IJCAI/ECAI volumes before event lookup, and selects same-year events by event_key. Incremental manifests for a named or ambiguous event must state event_key; their parent count and optimistic update are checked against that exact event, not the first venue/year/track match.

Query filters compose event_key, status, tags and research type. An earlier rejected attempt and a later known acceptance remain distinct; neither annotations nor track names infer a research type. Installing this code does not initialize annotation_events. Event plans count that optional table when present, alongside the original business rows. Annotation initialization and event identity upgrade remain explicit commands with their own transactional checks. Neither command imports historical records.

Production sequencing

  1. Verify the exact integrated commit on the approved ces-control runner, including the real PostgreSQL interaction tests and wheel/installed CLI checks.
  2. Stage that exact source in a separate release directory and verify package hashes; leave the current runtime and frozen SQLite backup intact.
  3. Inspect live writers and coordinate through the existing database writer lock. Generate a fresh read-only event plan using that integrated release. Check its database/schema identity, all business counts and preserved history hashes. A plan from before further data or optional-schema changes must not be reused.
  4. Apply only that reviewed file with its actual SHA256, in one transaction. Independently verify the constraint, original edition IDs and fields, assigned Fall source, source and history bytes, ordinary queries, full-text queries and foundry health.
  5. Use the verified integrated release for subsequent writes. Older writers lacking event identity support must not resume against the upgraded schema. Annotation initialization requires a separate explicit operation and acceptance.

These are operational requirements, not claims of completed production deployment. The production event-key migration and optional annotation activation have not occurred at preparation time. Existing migration/import/repair acceptance remains valid; do not rerun those jobs to install source code. Cross-feature tests use disposable fixtures and PostgreSQL schemas, never the production research tables.

Coverage output also returns event_key for each independent edition ID. Two same-year main events keep their own status/source counts; venue paper totals remain distinct work counts rather than sums across events. Legacy datasets without the event column return an empty event key and remain read-only compatible.