administrator/DocForge2
1
0
Fork 0
Code Issues Pull requests Projects Releases 2 Packages Wiki Activity Actions Pages

Add project-bound graph visualization

Browse source
This commit is contained in:
Andraxion 2026-07-24 16:01:03 -04:00
parent 6b5c3a939a
commit 195a57210a
13 changed files with 1298 additions and 22 deletions
Download patch file Download diff file Expand all files Collapse all files

21
ACTIVE_SLICE.md
View file

@ -1,17 +1,14 @@
# Active slice
All planned DocForge gates, DFG-0 through DFG-9, are complete. No implementation gate is active.
```text
Slice: DFG-9 controlled application decision (complete)
Goal: Decide from DFG-7 and DFG-8 evidence whether a developer-only canonical changeset application command is justified.
In scope: Review read-only and proposal workflow evidence; define the exact human authorization boundary; evaluate repeated integration work; require clean base hashes and repeat validation; and either specify one narrow application command or record manual integration as permanent policy.
Out of scope: OpenClaw canonical application; automatic commit, push, deployment, or publication; arbitrary commands; accounts; HTTP transport; a web UI; and implementation before the evidence review supports it.
Done when: The project records either a proven narrow developer-only application contract or a reasoned decision to keep proposals manually integrated.
Owners: DocForge owns proposal evidence and generic safety constraints. Each project owns canonical source semantics and integration policy. A developer retains authorization, review, build, Git, and publication ownership.
Decision: Manual canonical integration is the permanent DocForge 0.x policy. No application command was added.
Proof: DFG-8 required one reviewed content replacement after DocForge had already validated, diffed, and previewed the proposal. It completed without failure or material repeated work. An application command would add canonical writers, authorization, rollback, and project-format ownership without measured need. Existing protocol and proposal tests prove that MCP and proposal workflows cannot alter canonical sources.
Slice: DFG-10 project-bound graph visualization (complete)
Goal: Make a configured DocForge graph directly inspectable through one lightweight, generic, read-only web interface started by MCP.
In scope: One fixed `docforge_visualize` MCP tool; one built-in HTML/CSS/JavaScript template; loopback-only ephemeral HTTP; an unguessable per-process URL token; project-bound overview, search, exact-node, and bounded-neighborhood reads; deterministic graph layout; stale-index rejection; adapter compatibility; lifecycle and cross-project isolation tests; and contract/version documentation.
Out of scope: Arbitrary database paths; arbitrary SQL; canonical or derived writes; project selection; external network binding; accounts; persistent web hosting; project-specific templates; code execution; Git, build, deployment, or publication operations; and changeset application.
Done when: Generic and adapter projects can invoke the same MCP tool, receive a loopback URL, inspect only their validated graph, and pass protocol, security, lifecycle, cross-project, formatting, type, and complete test gates.
Owners: DocForge owns the fixed visualization template, read-only HTTP boundary, token, query limits, and index validation. The configured project owns canonical facts and adapter extraction. The MCP process owns the visualization lifetime. The user owns opening the returned local URL.
```
**Next gate:** None planned. Monitor real adoption. Reopening canonical application requires a new
approved gate and measured evidence under `docs/APPLICATION_DECISION.md`.
**Next gate:** None planned. Measure actual graph-browser use before extending layout, export, or
remote-access policy. Canonical application remains permanently out of scope under
`docs/APPLICATION_DECISION.md`.