Repository navigation
Add durable nightly knowledge review, correction and containment - #328
Conversation
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 08f5ddc114
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| usage = _issue_usage(packet, view=service.view) | ||
| self._remember_context(context_id, request.expected_head_sha.casefold(), | ||
| tuple(row.to_dict() for row in request.carried_findings), service.view, usage) |
There was a problem hiding this comment.
Accumulate provenance for adaptive follow-up reads
The stored usage receipt covers only the packet produced by plan_adaptive. The public read_knowledge_context, search_knowledge_context, related_knowledge_context, and expand_knowledge_context operations can subsequently deliver additional knowledge, but they neither update the remembered receipt nor create another receipt checked by validate. In an adaptive review that follows one of those references, a hold added after that retrieval can therefore leave the initial receipt allowed and permit publication even though the review consumed the newly held page. Bind every session delivery into the completion receipt or validate the complete session delivery ledger.
Useful? React with 👍 / 👎.
| binding = resolve_snapshot_repo(view, selector) | ||
| if binding is None: | ||
| raise RuntimeError("containment requires a registered pinned repository") | ||
| with configured(maintenance): | ||
| usage = _issue_usage({"scope": "snapshot", "repository": binding.repo_id, | ||
| "review_id": run_id, "knowledge_snapshot": view.public_snapshot, | ||
| "knowledge_tree_sha256": view.tree_sha256}, mode="strict", view=view) |
There was a problem hiding this comment.
Issue Strict provenance against the configured knowledge tree
When settings.knowledge_dir differs from the packaged tree, the existing code pins that configured directory and the child reads it through KNOWLEDGE_DIR, but containment still resolves the repository and issues snapshot usage against the original packaged view. A repository present only in the configured tree now fails reservation, while extra or differing configured pages are absent from the receipt checked before result publication. Construct the containment view from the same knowledge_dir recorded in the pin so the receipt covers the bytes the Strict run actually consumes.
Useful? React with 👍 / 👎.
| from .knowledge_service.containment import configuration, knowledge_usage_record | ||
| if configuration()["enabled"]: | ||
| return {**packet, "knowledge_usage": knowledge_usage_record(packet)} |
There was a problem hiding this comment.
Mark adaptive MCP model content as injected
For an adaptive MCP review, packet["model_content"] is returned directly in the tool result and thus enters the model context, yet this call leaves injected=False. The resulting receipt exports these units only as retrieved, so maintenance.impact, which queries injected usage to schedule reassessment, misses reviews influenced by a contradicted unit, and selection also loses the intended injected-content weighting. Record this adaptive packet with injected=True.
Useful? React with 👍 / 👎.
Admitted knowledge can contain an early misunderstanding even when its source code and content never change. Add an opt-in nightly maintenance lane inside the existing knowledge scheduler that rechecks original, version-pinned evidence and governs correction through the existing review, publication, merge and activation gates.
kb maintain plan|run|statusandkb correction resolve, plus public consumer SDK APIs. Queue work through the existing service lease; preserve append-only decisions and receipts.Validation: full offline suite plus dependency-corrected MCP reruns; final focused maintenance, containment, existing scheduler/gates, SDK and Direct/Strict regressions; knowledge/doc/SPEC validators; wheel build and paired consumer integration. Tests include unchanged-source errors, unsupported references, malformed/missing witnesses, pause/restart/budget idempotence, protected rules, real source calibration, signed merge/activation/restoration and old snapshot/cache/rollback containment. No paid model calls or production state changes were used for validation.
Operator setup and rollout sequence:
doc/architecture/knowledge-maintenance.md.