Skip to content

Context Injection And Graphify

ClarusIubar edited this page Jun 16, 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 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 Versus Graphify

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

Same Workflow As Mermaid

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

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, 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

Relationship Model

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

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?

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