Skip to content

Context Injection And Graphify

Jump to bottom
ClarusIubar edited this page Jun 7, 2026 · 10 revisions

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.

Current Preview Readback

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 Versus Graphify

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

Same Workflow As Mermaid

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"]
Loading

Same Workflow As Explainable Nodes

The same flow can be represented as nodes that explain why context was injected:

Graphify-style explainable context nodes

Module Graph From Preview Source

The higher-density view below is generated from the preview repository's Python source imports, 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.

Graphify module graph

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 or boundary helper used through dynamic dispatch, CLI registration, tests, or runtime configuration 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 to modules outside the selected 53-node preview.
  • The module is intentionally isolated as a boundary contract. For example, authority, architecture, runtime acceptance, and model modules can be important even when 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 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

Relationship Model

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
Loading

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?

Authority Boundary

Graphify output must not grant edit authority. In this project, authority comes from:

  • GitHub child issue and checklist
  • workspace/repo/branch match
  • context start task 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.

Clone this wiki locally