Skip to content

Drain a fix entry into the concept store #268

Description

@sameera

As a developer whose fix carries a recorded reason, I want the distiller to drain the fix entry, so that the reason lands as a decision log entry on the page it belongs to.

Acceptance Criteria

  • Given .nexus/tmp/fix-<n>/ holding both epic.md and close-record.md, when /nxs.distill runs, then it discovers that directory as a drainable entry alongside .nexus/tmp/epic-<n>/.
  • Given a fix directory missing either file, when /nxs.distill runs, then it skips the entry, the same way it skips an epic entry missing either file.
  • Given a drained fix entry, when the changed page is read, then it carries one new decision log entry holding the reason the developer gave, and that entry's heading carries the provenance reference recorded in link.
  • Given a discovered fix entry, when the drain computes its deltas, then every delta is an update, and no delta creates a page, retires a page, adds or removes a touches neighbour, or sets domain.
  • Given a discovered fix entry, when the drain writes its deltas, then each changed page gains exactly one decision log entry.
  • Given a fix entry whose recorded reason maps to no page that already exists, when the drain processes it, then it reports a per-entry hard block named no-existing-page, writes nothing for that entry, and leaves the directory in place for a later run.
  • Given a fix entry whose recorded range.head is not an ancestor of the trunk, when the drain runs its merge precondition, then the entry fails that precondition under the existing two-test form.
  • Given a drained fix entry, when the drain reaches the step that removes committed entries, then it removes nothing for that entry and reports no missing removal target.
  • Given a fix entry and an epic entry discovered in the same run, when the drain completes, then the epic entry is drained exactly as it was before this change.
  • Given a drained fix entry, when the reciprocity fan-out and the atlas regeneration run, then both run unchanged and neither produces a change for that entry.

Notes

Consumption derivation needs no widening. A fix entry's provenance token is #<n> or <owner>/<repo>#<n>, which is exactly what the existing matcher handles in structured positions. A fix that succeeds always leaves a provenance token, because the razor requires exactly one appended entry per changed page and that entry's heading is a structured provenance position.

A fix whose reason maps to no page is the razor firing correctly, not a defect in the lane. A decision with no page is a decision that needs a page, and creating pages is epic work.

The reciprocity fan-out is vacuous by construction here, because a fix entry may not add or remove a touches neighbour. Atlas regeneration is a no-op in practice for the same reason, but it still runs so the atlas check cannot drift.

story_type: system · size: M

Metadata

Metadata

Assignees

No one assigned

    Labels

    pipelineOrchestration of the Nexus stages and human-decision gatesstoryUser story (created by nxs-gh-create-story)

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions