decision-framework DF-ROS-HISTORY-2026-0001
Historical ROS Attribution and Compatibility Policy
Historical ROS Attribution and Compatibility Policy
Context
The repository contains material work completed before ROS installation on 2026-08-17. Treating that work as if it had emitted live ROS transitions would fabricate process history. Ignoring it would leave future attribution and handoff incomplete.
The repository also contains two current-state documents and legacy artifact identifiers and filenames. A historical migration needs one authority rule and non-destructive compatibility behavior.
Decision
- Historical work is reconstructed into
.ros/history/historical-work.jsonlunder schema version1.0.0. Every record setshistorical: true, records its reconstruction method and confidence, and remains separate from the live append-only.ros/events/events.jsonlstream. - Historical records may satisfy path-attribution validation only after their schema, migration ID, semantic state, and referenced commits validate. They cannot carry live transition fields or authorize state transitions.
- Coherent objectives are grouped when commit-level separation would create trivial or misleading work items. Distinct decisions, evidence limitations, and original identifiers remain visible in the human index and record data.
- Root
CURRENT-STATE.mdis the authoritative repository state. Thecontext/CURRENT-STATE.mdfile is a compact ROS entry point derived from and linking to the root record; it must not assert competing project state. - Existing accepted or widely referenced artifact identifiers and filenames remain valid. Historical records use current canonical paths while notes and source audits preserve legacy path provenance. Renames require an explicit migration map only when a future change actually alters an identifier.
- Generated publisher output, registries, inventories, and build reports are derivative evidence. They may demonstrate a generator run or aid discovery, but they are not independent evidence for the underlying research claim.
Alternatives Considered
- Insert synthetic events into
.ros/events/events.jsonl: rejected because it would impersonate original live ROS transitions and timestamps. - Create one record per commit: rejected because merge commits, cleanup commits, and publisher follow-ups would obscure coherent objectives.
- Rename legacy artifacts to the current identifier convention: rejected because it would create avoidable compatibility churn and weaken provenance.
- Keep both current-state files canonical: rejected because their present claims conflict and agents need a single authoritative continuation record.
Consequences
- Historical attribution is queryable and validation-aware without rewriting Git history.
- Reconstruction confidence and missing evidence stay explicit.
- Live ROS transitions retain exclusive authority over current workflow state.
- Future agents start with root
CURRENT-STATE.mdand use the context file only as a concise ROS-oriented pointer.
Reversal Conditions
Supersede this decision if ROS adopts a first-class signed historical-event protocol with an equally strict separation from live transitions, or if the repository adopts a different canonical state location through an accepted governance change and migration plan.