45 lines
2.9 KiB
Markdown
45 lines
2.9 KiB
Markdown
# 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.
|