[umi008]

What does this PR do?

With --persistence true on a read-only repository, index_repository reported status: "error" with the hint "Pipeline failed. Check repo_path exists and contains source files" — blaming the repository for a failure that is actually the post-publish team-sharing artifact export (.codebase-memory/ cannot be written inside a read-only checkout). The graph database itself published fine.

The pipeline now snapshots the artifact export error of the run it just executed (a per-pipeline buffer, not the process-global export error which can describe a previous run). index_repository consults that snapshot on failure and names the real cause: the artifact export, the error detail, and the remedies (writable checkout or --persistence false). Every other failure path keeps the existing hint byte-for-byte.

The fail-hard semantics are unchanged: a failed persistence export still makes the run fail, which is the in-tree documented decision (export_after_publish, "intentionally fails the run"). This change only makes an already-failing run report the truth — the issue-1466-era misleading repo_path hint is what hid the cause.

Verified with a reproduce-first pipeline test: an artifact directory blocked (.codebase-memory as a file), fixture indexed, asserts rc != 0, cbm_pipeline_export_error() non-empty and naming the artifact phase, the DB still published, and a clean re-run leaving the snapshot empty.

Checklist

• Every commit is signed off (git commit -s) — required, CI rejects unsigned commits (DCO, see CONTRIBUTING.md)
• Tests pass locally (make -f Makefile.cbm test)
• Lint passes (make -f Makefile.cbm lint-ci)
• New behavior is covered by a test (reproduce-first for bug fixes)

[github-actions]

Thanks for opening this — it has been seen, and it is queued.

This note is automated, but it is not a brush-off: it exists so you know where your PR stands instead of having to guess from silence.

Current review status: working through a backlog. 0.9.1-rc.1 is out, so the release freeze that held reviews is over — but it left a large queue of open pull requests behind it, and we are reading through them oldest-first. The background is in discussion #1144.

What that means for this PR, concretely:

• It will not be closed for inactivity. No stale bot touches pull requests here.
• It may still sit a while before a human reads it. That is on us, not on you.
• Older PRs are read first, so a recent one is not being skipped — it is behind a queue.

Things that will genuinely speed it up whenever review does happen:

• Keep it rebased on main — the tree is moving quickly right now, and a conflicting branch cannot be reviewed as the diff you intended.
• Get CI green, or say which failures you believe are pre-existing.
• Keep the change to one claim. Bundled features and refactors get split before they get merged, which costs you a round trip.
• Every commit needs a sign-off (git commit -s) — CI enforces DCO.

If this fixes a bug, a reproduction we can run is worth more than a description of the symptom.

Thanks for contributing, and sorry in advance for the wait.

[DeusData]

Thank you for tracing the misleading error to the post-publish artifact phase and for preserving the existing fail-hard contract. I checked current main: artifact export logs its own phase error, but the MCP failure path still returns the generic “Pipeline failed. Check repo_path” hint. That confirms the attribution problem.

Before code review, please remove the 135 lines under the five new openspec/ files. Current main has no openspec/ tree, and CONTRIBUTING.md requires prior approval for project configuration. The focused mcp.c, pipeline, header, and regression-test changes can remain together as the single bug fix. I have labeled this as a normal-priority UX bug. Splitting enables review but does not pre-decide the merge outcome. Thank you for making the existing failure report the actual cause.

[DeusData]

Approved on merit. One thing to remove first.

Please drop the openspec/ files

Five of the nine files here are openspec/ spec-framework scaffolding. openspec/ does not exist on main, no other contributor uses it, and adopting it is a project-level decision rather than something a bug fix should bring in. We have decided not to adopt it — please strip openspec/ and keep src/ plus tests/. Same request on #1788 and #1790.

The analysis itself is welcome; put it in the PR description, where reviewers actually read it. It is the permanent config and per-change archive tree in a lean C repo that we are declining, not your reasoning.

On the fix

This is a good defect to have chased, because the bug was a lie rather than a silence. index_repository reported

Pipeline failed. Check repo_path exists and contains source files

for a run where the repository was fine and the graph database published successfully — the failure was the post-publish artifact export unable to write .codebase-memory/ into a read-only checkout. A user following that hint goes and checks their repo path, which is correct, and learns nothing. Misdirection costs more than a bare failure.

Two decisions I want to name because they are what make this safe:

Snapshotting the artifact export error of the run just executed, rather than reading the process-global export error. That global could describe a previous run, so consulting it would occasionally attach a stale, unrelated cause to a fresh failure — which is the same class of bug you are fixing, reintroduced one level up. A per-pipeline buffer is the right shape.

Leaving the fail-hard semantics alone. A failed persistence export still fails the run, per the in-tree export_after_publish decision. You changed only what an already-failing run says, and said so explicitly. That is the difference between a diagnostics fix and a behavior change smuggled in as one, and keeping every other failure path byte-for-byte is what lets me take this without a broad regression hunt.

Strip openspec/ and I will merge on green. Our Actions queue is heavily backlogged at the moment (30 runs queued), so expect a wait that has nothing to do with this PR.

[DeusData]

Thank you, @umi008! Your fix is now on main through #2247 (merge commit 2b4084f). It carries your change with a Co-authored-by: Ulises Millan Guerrero trailer, so the credit stays in the history. You found the real problem: on a read-only checkout, index_repository blamed the repository when the post-publish artifact export was what actually failed. The error now names the artifact export phase, as you proposed.

We carried it in a separate PR rather than merging this one only because five of the nine files were openspec/ scaffolding. Adopting a spec framework is a project-level decision that shouldn't ride along with a bug fix. That's no judgement on the work itself, which was careful and correct. Closing this one now that the fix has landed. Thanks again, and we'd be glad to see more from you.