-
Notifications
You must be signed in to change notification settings - Fork 0
Context Injection And Graphify
This project is not only a checklist policy. It also models which context is allowed to enter an agent session and which context remains advisory.
The v0.2.0 release work used the same task-hydration model documented in the repository. The relevant readback for this release was:
Status: task-hydrated
Execution phase: implementation-ready
Task context injection: task-hydrated; task context injected after workspace match
Workspace repo: ClarusIubar/agent_bootstrap-preview
Branch: main
Child task: TSK-001-02
Edit gate: implementation-ready
That means the agent did not rely only on chat memory. The repository, branch, parent issue, child issue, checklist, architecture boundary, and validation contract were hydrated before source refresh, README edits, graph generation, wiki edits, and release work.
The same readback separates context aids from authority:
Controlled context manifest: controlled-context-manifest.v1
qmd context aid: not-ready
Graphify context aid: not-ready; blockers=current context pack missing
Hermes promotion candidates: current=0
This is intentional for a sanitized preview. The GitHub child issue/checklist and local policy files grant edit authority. Graphify remains an explanation and recovery aid unless an explicit current-repo context pack is generated.
Mermaid is the right format for a compact reviewer-facing control-flow sketch. Graphify is the richer model for explainable context relationships.
| Surface | Primary Use | Strength | Limitation |
|---|---|---|---|
| Mermaid | Human-readable workflow diagram | Easy to inspect in Markdown and Wiki | Static diagram; not a queryable context model |
| Graphify-style context graph | Explainable nodes and relationships | Shows why a file, issue, command, or evidence item is relevant | Must be generated from an explicit scoped context pack |
| Module graph PNG | Public source-structure evidence | Shows interface locality, adapter layers, and boundary nodes | Filtered to keep labels readable |
| Task hydration readback | Edit authority gate | Tells whether the agent may edit now | Should not become a broad memory dump |
| Controlled context manifest | Context surface classification | Separates qmd, Graphify, ambient hints, and Hermes candidates | Readback only; not authority by itself |
flowchart TD
Request["User request"] --> Parent["Parent issue"]
Parent --> Child["Child issue"]
Child --> Checklist["Checklist and validation contract"]
Child --> Boundary["Architecture boundary gate"]
Checklist --> Hydration["context start"]
Boundary --> Hydration
Hydration --> Gate["Edit gate"]
Gate --> Files["Scoped file changes"]
Files --> Tests["pytest + sensitive scan"]
Tests --> Commit["Commit and push"]
Commit --> CI["GitHub Actions readback"]
Commit --> Wiki["Wiki commit"]
CI --> Release["v0.2.0 release"]
Wiki --> Release
Release --> Evidence["Completion evidence"]
The same flow can be represented as nodes that explain why context was injected:

The higher-density view below is generated from the preview repository's Python
source imports at source baseline cc2e007dc7ce9315633b3b6146557df082b77006,
then grouped into heuristic columns. This is closer to the original Graphify
module graph style: interface locality, facades/adapters, qmd, Graphify, Hermes,
boundary/gate, and runtime/state layers.

Direct image files:
Dashed nodes are not missing modules. They are modules that have no visible left-to-right link in this filtered layer view. That can happen for three reasons:
- The module is a leaf utility, boundary helper, dynamic-dispatch target, CLI registration target, test seam, or runtime configuration helper rather than a direct import edge in the selected slice.
- The module has relationships that were filtered out to keep the public reviewer graph readable, such as reverse imports, same-column imports, or links outside the selected preview slice.
- The module is intentionally isolated as a boundary contract. Authority, architecture, runtime acceptance, and model modules can be important precisely because they should not freely import across layers.
So a dashed node means "standalone in this rendered slice," not "dead code" and not "missing context." A full Graphify context pack can preserve those relationships as queryable metadata; the Wiki PNG keeps the public view readable.
| Explainable Node | Example In v0.2.0 | Why It Matters |
|---|---|---|
Repository |
ClarusIubar/agent_bootstrap-preview |
Bounds work to the intended preview repo |
SourceBaseline |
cc2e007dc7ce9315633b3b6146557df082b77006 |
Records the latest source snapshot used for refresh |
Branch |
main |
Prevents branch/worktree ambiguity |
ParentIssue |
TSK-001-00 |
Holds roadmap and public-preview purpose |
ChildIssue |
TSK-001-02 |
Holds executable release scope and checklist |
ChecklistItem |
source refresh, README, docs, tests, wiki, release | Maps work to explicit requirements |
ArchitectureBoundary |
preview docs, scripts, tests, remote boundary | Explains responsibility and dependency direction |
ChangedFile |
README.md, CHANGELOG.md, docs/, tests/, wiki pages |
Shows which artifacts implement the checklist |
ValidationCommand |
python -m pytest, sensitive-string scan |
Proves behavior and sanitization locally |
CIReadback |
GitHub Actions Test success |
Confirms remote validation |
GitHubRelease |
v0.2.0 |
Provides public release evidence |
CompletionEvidence |
issue comments and readbacks | Preserves why the task is considered handled |
flowchart LR
Repo["Repository"] --> Branch["Branch"]
Source["Source baseline"] --> Task["Hydrated child task"]
Branch --> Task
Task --> Checklist["Checklist items"]
Task --> Boundary["Architecture boundary"]
Checklist --> Files["Changed files"]
Boundary --> Files
Files --> Validation["Validation commands"]
Validation --> Commit["Commit"]
Commit --> CI["CI readback"]
Commit --> Wiki["Wiki commit"]
CI --> Release["Release"]
Wiki --> Release
Release --> Evidence["Completion evidence"]
Graphify can make these relationships queryable when a context pack is generated. Example reviewer questions:
- Which changed files map to the sanitized preview checklist?
- Which validation commands prove those files?
- Which commit and CI run correspond to the final preview state?
- Which wiki page explains the workflow and context-injection model?
- Which context surfaces were authority, and which were advisory?
Graphify output must not grant edit authority. In this project, authority comes from:
- GitHub child issue and checklist
- workspace/repo/branch match
-
context starttask hydration - validation and remote readback before completion
Graphify is valuable because it can explain and recover relationships after the fact. It remains advisory unless the task gate says the work is hydrated and implementation-ready.