Skip to content

I0602 — Make a local override explicit and prove it survives an update of the shared source

Define how a repository overrides part of a shared policy, require the override to be declared rather than inferred from a value differing, and prove with a case that updating the shared source leaves the override standing.

BLOCKED wave 1 · p3 · implementation profile · runs alone

Part of shared-policy — Shared policy across repositories and workers.

Blocked. This issue cannot start until I0601, milestone:shared-policy are done. The status is derived from that, not declared.

Objective

Define how a repository overrides part of a shared policy, require the override to be declared rather than inferred from a value differing, and prove with a case that updating the shared source leaves the override standing.

Why

An override that looks like an ordinary key is indistinguishable from a stale copy. Declaring it is what lets the drift report tell a deliberate exception from an accident.

Current state

A shared source can be named and resolved. Anything a repository writes locally either wins or loses by a rule nobody has written down.

Desired state

Overrides are declared, the merge order is documented and tested, and a shared source that changes underneath a repository does not silently take an override away.

Scope

  • lib
  • share
  • docs

Out of scope

  • Overriding a rule the shared policy declares non-overridable, if such a class is introduced later

Dependencies

What waits on this

Acceptance criteria

  • An override is a declaration, and a local value that differs without one is a finding
  • The merge order is documented and covered by a case
  • A case updates the shared source and shows the override still applies

Validation

  • bash test/run.sh

Evidence required

  • suite

Evidence

None recorded. Every token above needs a command or an artifact behind it before this issue can be completed; narrative is refused.

Risk

Merge semantics are where shared configuration usually becomes unexplainable; the documented order and its case are the whole defence.

Timeline

started
—
verified
—
completed
—

Those three fields, the evidence above and the state of the dependencies are all the status is made of. There is no status field to disagree with them.

Canonical record: .ai/repo/project/issues/I0602.yaml. Read it back with majordomus plan show I0602.