Description
When corpus_get_coverage is called for a repository that is not present in the local corpus, GitContribute correctly reports the target as unavailable, but the recovery guidance is only a generic sentence. The result does not identify the advertised synchronization operation or provide the arguments needed to continue.
Observed response:
{
"status": "partial",
"items": [{
"item_status": "unavailable",
"key": "morluto/leantoken",
"message": "target is not present in the local corpus",
"reason": "not_indexed",
"next_action": "Synchronize the repository or thread explicitly, then retry this item."
}]
}Steps to Reproduce
- Use a GitContribute installation whose local corpus does not contain a repository.
- Call
corpus_get_coverage with:
{"targets":[{"owner":"morluto","repo":"leantoken"}]}
- Inspect the item-level result.
Expected Behavior
The result should preserve the current unavailable / not_indexed classification, but expose an actionable recovery route. For example, it could return a structured next action containing the exact advertised synchronization tool, its repository or thread arguments, the facets to acquire, and the instruction to retry coverage afterward.
The contract and tool descriptions should also state explicitly that not_indexed means unknown coverage, not evidence that no issue, PR, or code match exists.
Synchronization should remain explicit and bounded: corpus reads must not perform network access implicitly. This report is about discoverability and routing, not a request to make every coverage read auto-sync.
Actual Behavior
The only recovery hint is:
Synchronize the repository or thread explicitly, then retry this item.
An agent has to guess which synchronization operation applies and reconstruct its arguments. Depending on the workflow, it may stop, make an incorrect sync call, or incorrectly treat unavailable coverage as a negative result.
Impact and Scope
This affects workflows that correctly check coverage before searching for duplicates, historical precedents, or source evidence in a repository that has not yet been synchronized. The underlying coverage classification is useful; the missing actionable route makes the normal recovery path unreliable.
Possible Direction
One option is to return a structured next_action object, for example:
{
"kind": "sync_required",
"tool": "github_sync_threads",
"arguments": {
"repositories": [{"owner": "morluto", "repo": "leantoken"}]
},
"then": "corpus_get_coverage"
}The exact operation and arguments should be selected from the missing facet rather than hard-coded to one sync tool. A dedicated ensure_coverage operation is another possible design. Either approach should have focused coverage for an unindexed repository, an unindexed exact thread, stale coverage, retryable sync results, and the invariant that corpus reads remain network-free.
Description
When
corpus_get_coverageis called for a repository that is not present in the local corpus, GitContribute correctly reports the target as unavailable, but the recovery guidance is only a generic sentence. The result does not identify the advertised synchronization operation or provide the arguments needed to continue.Observed response:
{ "status": "partial", "items": [{ "item_status": "unavailable", "key": "morluto/leantoken", "message": "target is not present in the local corpus", "reason": "not_indexed", "next_action": "Synchronize the repository or thread explicitly, then retry this item." }] }Steps to Reproduce
corpus_get_coveragewith:{"targets":[{"owner":"morluto","repo":"leantoken"}]}Expected Behavior
The result should preserve the current
unavailable/not_indexedclassification, but expose an actionable recovery route. For example, it could return a structured next action containing the exact advertised synchronization tool, its repository or thread arguments, the facets to acquire, and the instruction to retry coverage afterward.The contract and tool descriptions should also state explicitly that
not_indexedmeans unknown coverage, not evidence that no issue, PR, or code match exists.Synchronization should remain explicit and bounded: corpus reads must not perform network access implicitly. This report is about discoverability and routing, not a request to make every coverage read auto-sync.
Actual Behavior
The only recovery hint is:
An agent has to guess which synchronization operation applies and reconstruct its arguments. Depending on the workflow, it may stop, make an incorrect sync call, or incorrectly treat unavailable coverage as a negative result.
Impact and Scope
This affects workflows that correctly check coverage before searching for duplicates, historical precedents, or source evidence in a repository that has not yet been synchronized. The underlying coverage classification is useful; the missing actionable route makes the normal recovery path unreliable.
Possible Direction
One option is to return a structured
next_actionobject, for example:{ "kind": "sync_required", "tool": "github_sync_threads", "arguments": { "repositories": [{"owner": "morluto", "repo": "leantoken"}] }, "then": "corpus_get_coverage" }The exact operation and arguments should be selected from the missing facet rather than hard-coded to one sync tool. A dedicated
ensure_coverageoperation is another possible design. Either approach should have focused coverage for an unindexed repository, an unindexed exact thread, stale coverage, retryable sync results, and the invariant that corpus reads remain network-free.