-
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 preview preparation work was run through the same task-hydration model documented in the repository. The relevant readback for the current work 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-01
That means the agent did not rely only on chat memory. The current repository, branch, parent issue, child issue, and checklist were hydrated before implementation and wiki updates.
The same readback also 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 the intended behavior for a sanitized preview. Task context injection is active, while Graphify remains a recovery/explanation aid until an explicit current-repo context pack exists.
Mermaid is the right format for a reviewer-facing diagram. Graphify is the right 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 | Can answer why a file, issue, command, or evidence item is relevant | Must be generated from an explicit scoped context pack |
| 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"]
Checklist --> Hydration["context start"]
Hydration --> Gate["Edit gate"]
Gate --> Files["Scoped file changes"]
Files --> Tests["Validation commands"]
Tests --> Commit["Commit and push"]
Commit --> Readback["Remote and CI readback"]
Readback --> Evidence["Completion evidence"]
The same flow can be represented as nodes that explain why context was injected:
| Explainable Node | Example In This Preview | Why It Matters |
|---|---|---|
Repository |
ClarusIubar/agent_bootstrap-preview |
Bounds work to the intended repo, not the private source repo |
Branch |
main |
Prevents branch/worktree ambiguity |
ParentIssue |
TSK-001-00 |
Holds roadmap and public-preview purpose |
ChildIssue |
TSK-001-01 |
Holds executable scope and checklist |
ChecklistItem |
prepare README, docs, tests, wiki | Maps work to explicit requirements |
ArchitectureBoundary |
reviewer docs, scripts, tests, remote boundary | Explains responsibility and dependency direction |
ChangedFile |
README.md, docs/, tests/, wiki pages |
Shows which artifacts implement the checklist |
ValidationCommand |
python -m pytest, sensitive-string scan |
Proves behavior and sanitization locally |
Commit |
0a6aec8e7189515c7432a6c7e9af8f3c8854c47f |
Gives immutable repository evidence |
CIReadback |
GitHub Actions Test success |
Confirms remote validation |
WikiCommit |
e7612b37302cb4b80e52c33f5f1d415d43ba2d3a |
Gives separate wiki publication evidence |
CompletionEvidence |
issue comments and readbacks | Preserves why the task is considered handled |
flowchart LR
Repo["Repository"] --> Branch["Branch"]
Branch --> Task["Hydrated child 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 --> Evidence["Completion evidence"]
Wiki --> Evidence
Graphify can make these relationships queryable when a context pack is generated. Example questions a reviewer should be able to ask from a graph:
- 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.