> ## Documentation Index
> Fetch the complete documentation index at: https://docs.comet.rpamis.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Real Case: Delivering Project Knowledge Engine with Supervisor Change

> Review an archived Supervisor Change in the Comet repository to understand how large-scale capabilities are split, integrated, fixed, and unified for acceptance.

export const SupervisorVideo = ({src, width, height, label, fallback}) => <div className="comet-home__supervisor-media">
    <video autoPlay muted loop playsInline controls preload="metadata" width={width} height={height} aria-label={label}>
      <source src={src} type="video/mp4" />
      {fallback}
    </video>
  </div>;

This page reviews the `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 the `agent-project-knowledge-engine` archive.

<SupervisorVideo src="/vedio/codex.mp4" width={1230} height={858} label="Comet Supervisor Change Advances child through multiple independent tasks in Codex" fallback=" Your browser does not support HTML5 video" />

## 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.

These constraints need to be uniformly accepted after all the integration is fully implemented. The independent passing of tests by a single module does not prove that the complete product objective has been established.

## Extract three feature children from the real dependencies

The `children.yaml` in the archive uses `comet.native.children.v2`. The initial implementation is split into three feature children based on actual dependencies:

| Child                                   | Dependency       | Main results                                                                           | "Implementation submission" |
| --------------------------------------- | ---------------- | -------------------------------------------------------------------------------------- | --------------------------- |
| `project-knowledge-hybrid-retrieval`    | no               | Query planning, SQLite section indexing, hybrid recall, index management and Retrieval | `d42226fb`                  |
| `project-knowledge-units`               | hybrid retrieval | Knowledge unit, deterministic extraction, source verification and one-hop relationship | `efe007c9`                  |
| `project-knowledge-learning-management` | knowledge units  | Controlled learning, Plugin Event, explicit sharing, CLI, Dashboard and Agent A/B      | `cca74993`                  |

These three children form a dependency chain:

```text theme={null}
project-knowledge-hybrid-retrieval
  → project-knowledge-units
    → project-knowledge-learning-management
```

Supervisor Change supports parallel execution and also supports tasks that are advanced in stages based on dependencies. The Runtime only places the child whose dependency has already been satisfied into `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:

| Integrated submission | Integrated result                                                                                                    |
| --------------------- | -------------------------------------------------------------------------------------------------------------------- |
| `6a230657`            | Merge hybrid retrieval, add 19 new files, and form the basis of SQLite indexing, CLI and retrieval evaluation        |
| `576f4c25`            | Integrate knowledge units, add deterministic extractors, knowledge unit storage and corresponding tests              |
| `be58f9cc`            | Integrate learning management to incorporate learning processes, management commands, Dashboard views, and Agent A/B |

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:

| Target cycle | Verify result | Problems discovered                                                                                                                 |
| ------------ | ------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
| 2            | failed        | There is still a substantial closed-loop gap between the research conclusion and its implementation                                 |
| 3            | failed        | Source credibility, workspace isolation, activation conditions, incremental costs, and comprehensive evaluation remain insufficient |

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 archived `children.yaml` has added a fourth child:

```yaml theme={null}
- name: project-knowledge-closure
  depends_on: [project-knowledge-learning-management]
  covers: [A4, A8, A10, A15, A19, A20, A27, A29, A30, A31]
```

`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 of `verification.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.

The full test simultaneously retained an existing `/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 as `de780ce2`. Then `58b6dfb2` merged `comet/agent-project-knowledge-engine` into `040rc1`.

The entire process is finally delivered only once at the parent level:

```text theme={null}
Three feature children
Three independent integrations
The parent verification failed in two rounds
→ 1 closure child
49 items were finally accepted and passed
  → Archive
Merge 040rc1
```

## Extract the splitting principle from this case

This real Change showcases four product features of Supervisor:

| Features                          | The performance in the case                                                                               |
| --------------------------------- | --------------------------------------------------------------------------------------------------------- |
| Dependent drive                   | The subsequent child will only start after the integration of the prerequisite capabilities               |
| Work area isolation               | Each child forms an independent candidate and is then integrated by the Runtime                           |
| Unified acceptance by the parent  | After the module test is passed, the complete product goals and cross-module boundaries are still checked |
| The scope of failure can be added | The final verified real gap forms a closure child and does not rewrite the integrated history             |

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 ](/en/native/supervisor-change), [Native Loop](/en/native/native-loop) and [Verification and Fix ](/en/native/verification-and-repair).