agent-project-knowledge-engine that have been delivered in the Comet repository. It was archived on August 22, 2026, and eventually entered 040rc1. The goals, children, dependencies, commits, and validation results in the case all come from the repository records.
This Change upgrades Project Knowledge from document retrieval that runs ripgrep in real time to agent-oriented project understanding capabilities. The final delivery includes SQLite FTS5 and ripgrep hybrid recall, Project Knowledge unit, controlled learning, CLI, Dashboard and evaluation system.
! Xiaoyu bound the achievements of the three children into the parent level for delivery and filled the final acceptance gap ](/assets/supervisor-change-delivery-illustrations/01-integrated-delivery.png)
The execution screen of Supervisor in Codex
The following screen recording shows the actual interface of Supervisor in Codex for creating independent tasks, allocating children, and continuous coordination. Screen recording is used to demonstrate the execution mechanism; The child, submission and acceptance data of this article still come from theagent-project-knowledge-engine archive.
Constrain multiple implementation stages with an overall goal
The transformation of Project Knowledge spans retrieval, indexing, knowledge models, plugin events, CLI, Dashboard and evaluation. Each part can be implemented in phases, but they must jointly meet one product goal: to reduce the repetitive exploration of the Agent, while continuing to take the current code, configuration and testing as the ultimate basis. The parent Change uniformly maintains the following boundaries:- By default, Local Provider uses a mixed recall of FTS5 and ripgrep. When FTS5 is unavailable, it retains the fallback function.
- Project Knowledge maintains independent ownership, storage and budget from Personal Memory;
- Project Knowledge must be accompanied by the current source and cannot replace code verification.
- Index failures, unreadable sources, and failed semantic adapters cannot block Workflows.
- CLI, Dashboard, generated assets, Retrieval, and Agent A/B use the same capability boundary.
Extract three feature children from the real dependencies
Thechildren.yaml in the archive uses comet.native.children.v2. The initial implementation is split into three feature children based on actual dependencies:
These three children form a dependency chain:
readyChildren each time. For subsequent child, start from the latest integration baseline to avoid early implementation based on unstable data structures or interfaces.
Each child forms integrable results in the isolated workspace
The three feature children are all implemented and verified in their own workspaces. They do not directly modify the target branch but first enter the integration branch of Supervisor. The repository retains three real integration commits:
Each child’s feature commit and integration commit are retained separately. The Runtime can thereby determine whether the candidates have been verified, whether the current integration baseline contains dependencies, and whether late results still apply to the current state.
The parent Verify exposes cross-module gaps
After the integration of the three feature children, the parent was not directly archived.verification.md recorded two rounds of failures:
These issues span multiple feature children. Reopening the already integrated child would disrupt the confirmed historical boundaries and make it difficult to express the new overall acceptance scope. Runtime retains the integration site and allows the parent to return to Shape to update acceptance and child declarations.
Append the closure child to converge the real failure
The final archivedchildren.yaml has added a fourth child:
project-knowledge-closure focuses on the gaps that have been observed by the parent Verify, including source boundaries, targeted refreshing, activation conditions, workspace isolation, and evaluation integrity. The subsequent repair submission did not expand the product goals but supplemented the implementation evidence within the existing acceptance scope.
Among them, 3cd0c25b completed the final round of review boundary fixes, involving knowledge units, learning processes, plugin integration, file storage, and two evaluation scripts. This child enables cross-module issues to have an independent scope while retaining the integration history of the first three feature children.
The final acceptance covers 49 behaviors
The second Verifier of the fourth target cycle passes. Final record ofverification.md:
- All 49 acceptance items were
passed. - Child verification, parent integration and parent checking have all been completed.
- focused tests, Native tests, typecheck and build have been executed;
- Three important issues of the independent code review have been fixed;
- There are no Critical issues or unfinished blocking items.
/comet Skill length baseline that was not related to this Change and failed. The archive did not rewrite it as “this capability pass”, nor did it allow irrelevant failures to overwrite the completed special evidence.
Deliver the target branch in one go after archiving
After the parent completes the verification, file it asde780ce2. Then 58b6dfb2 merged comet/agent-project-knowledge-engine into 040rc1.
The entire process is finally delivered only once at the parent level:
Extract the splitting principle from this case
This real Change showcases four product features of Supervisor:
The key basis for choosing the Supervisor Change is that the overall goal requires multiple independently verifiable results, and the parent still has an indispensable final acceptance. Whether sub-tasks can run simultaneously is only part of the execution efficiency. Clearly defining dependencies, isolating candidates, and unified delivery are equally important.
The case evidence is located in the Comet source code repository at
docs/comet/archive/2026-08-22-agent-project-knowledge-engine/. Continue reading: Supervisor Change Mechanism , Native Loop and Verification and Fix .