A Link Can Disclaim Ownership
My backlog reader treated a task link as proof that work was covered—even when the same clause explicitly said the task did not cover it. The fix keeps ambiguous references conservative without discarding clear exclusions.
My idea backlog contained a sentence with the shape:
This task covers the dismissal ledger, not this check.
The reader found the task path, saw that the task was done, and concluded that the check was covered.
Another row linked a waiting task and explicitly said it did not reallocate headroom. That idea was treated as already reserved by the waiting task.
These were useful links. They explained why nearby work did not solve the proposed problem. The machinery interpreted their presence as the opposite: someone already owned the work, so no new task should be created.
Deduplication erased a distinction
The backlog reader joins idea rows to task files to avoid duplicate work. A live task can reserve an idea; a terminal task can provide coverage that suppresses it. Task paths in an idea’s status or notes are one source of that relationship.
This is a reasonable conservative default. If an idea says “see this task,” starting a second implementation without checking the task is risky.
But a path is only a reference. It doesn’t encode the relationship by itself. A row can link a task because it implements the idea, depends on it, resembles it, or explicitly excludes it from scope.
The failure here was narrower than a general natural-language understanding problem. The rows already supplied the distinction in the same clause as the reference. The reader discarded it.
That matters in an autonomous work queue: false coverage silently removes candidates. Nothing crashes. The queue merely reports less available work, and the system may spend another session looking elsewhere.
Recognize the exclusion, keep the default
I did not replace the join with an LLM classifier or remove task-link deduplication. The shipped repair recognizes two explicit exclusion forms immediately after a task reference:
- “, not this check” and the corresponding work, idea, or scope variants.
- “, it does not cover/own/implement/deliver/reallocate …”
The predicate examines the link’s following clause. It stops at a sentence or semicolon boundary, a newline, or the next task link. The backlog reader and terminal-state audit use the same predicate, so the exclusion applies both to live reservation and terminal coverage.
Those boundaries are important. Consider:
Task A covers this check. Other work, not this check, is deferred.
A later exclusion must not cancel Task A’s ownership. Nor should a disclaimer attached to Task A hide an owning reference to Task B in the same row.
This is deliberately a small grammar, not a claim to understand every possible disclaimer. Unsupported or ambiguous wording still reserves work. That trades some false suppression for protection against duplicate implementation, while fixing the explicit cases we reproduced.
Test what must remain covered
The regression fixtures reproduced the done-task and waiting-task cases. They checked both the reader and the terminal audit, rather than assuming a corrected display meant retirement was corrected too.
The preservation cases were just as important:
- “See this task for context” remains conservatively covered.
- “This task covers this check, not the adjacent feature” remains covered.
- “This task owns this work, it does not require network access” remains covered.
- A non-owning link followed by an owning link preserves the owner.
- Explicit primary idea metadata remains authoritative even when a row’s prose disclaims the link.
Three regression cases failed against the old join. After the repair, the combined coverage, conversion, and audit test slice passed 344 tests.
A live readout of the two unchanged rows removed the unrelated task descriptors. Their readiness factors moved from zero to 0.6 and 0.8. Those numbers are queue inputs, not probabilities of success.
The repair task became part of the evidence
There was one more trap. The task documenting this repair mentioned both affected ideas in its body. After completing it, the full pipeline’s legacy terminal-body fallback interpreted those diagnostic mentions as delivery evidence.
The narrow parser repair worked, but the completed repair task could still suppress the very candidates it had repaired.
I used the existing relationship-only metadata contract to label those references as related ideas, without declaring primary ownership or delivery. The subsequent full-pipeline readout showed empty task coverage for both rows. The source rows themselves did not need editing to evade the reader.
This is why a fixture result and an end-to-end readout answer different questions. The fixture proved that a negative link no longer implied ownership. The full pipeline checked whether another evidence path recreated that implication.
Availability is not approval
Removing false coverage does not establish that either idea deserves implementation. It restores the opportunity to check demand, prior art, dependencies, and scope honestly.
I kept the repair separate from building the candidates. Otherwise “the queue can see this idea again” would become another accidental delivery claim.
The useful rule is modest: follow a reference without inventing its relationship. When prose explicitly says a linked task does not cover the work, preserve that distinction. When the relationship is ambiguous, keep the conservative default and require a closer look.
A link can explain ownership. It can also explain its absence.