62 lines
3.5 KiB
Markdown
62 lines
3.5 KiB
Markdown
# Canonical application decision
|
|
|
|
**Status:** DFG-9 complete.
|
|
|
|
**Decision:** DocForge does not apply changesets to canonical project files. Accepted proposals are
|
|
manually integrated through the owning project's established source, build, test, and Git workflow.
|
|
This is the permanent DocForge 0.x policy, not a deferred implementation item.
|
|
|
|
## Evidence
|
|
|
|
DFG-8 produced one real AssetForge proposal. DocForge automated source-hash checks, writer scope,
|
|
changeset storage, conflict detection, project validation, structured diffing, and escaped preview
|
|
rendering. The remaining integration step was one reviewed content replacement in one existing
|
|
Markdown chapter. That step completed without an integration failure, lost work, or material delay.
|
|
|
|
There is no recorded evidence of repeated manual-integration errors, costly multi-file application,
|
|
or another project requiring canonical application. A generic application command would therefore
|
|
add more authority and failure handling than the observed workflow needs. It would require:
|
|
|
|
- project-specific Markdown and TOML writers instead of the current read and validation adapters;
|
|
- atomic rollback across every affected canonical file;
|
|
- recovery when source application succeeds but a project build or validation later fails;
|
|
- a developer authorization boundary that cannot be reached through MCP or an agent writer;
|
|
- exact handling for create, move, delete, metadata, relationship, and manifest ownership; and
|
|
- new cross-project proof that the generic core does not assume Worldforge source semantics.
|
|
|
|
Adding those capabilities to remove one deliberate copy step would weaken the existing ownership
|
|
boundary without measured benefit.
|
|
|
|
## Permanent boundary
|
|
|
|
DocForge may read canonical sources and write only configured indexes, changesets, previews, and
|
|
declared derived renders. It may validate, diff, and preview a proposed graph. It does not write,
|
|
rename, or delete canonical sources through its library, CLI, or MCP server.
|
|
|
|
The developer or project owner retains these actions:
|
|
|
|
1. review the complete changeset diff and preview;
|
|
2. confirm the current canonical source and base hashes still match;
|
|
3. manually integrate only the accepted content through the project's canonical source owner;
|
|
4. run the project's builder, index refresh, tests, and generated-output checks; and
|
|
5. inspect, commit, push, deploy, or publish through the project's normal workflow.
|
|
|
|
If canonical state changes before integration, the proposal must be refreshed or recreated. A
|
|
developer must not bypass a stale or conflicting changeset by applying it mechanically.
|
|
|
|
## Reopening criteria
|
|
|
|
DFG-9 is closed. Canonical application may be reconsidered only through a new explicitly approved
|
|
gate with measured evidence of repeated integration failures or meaningful repeated work across
|
|
more than one project. That gate must define source-format ownership, developer authorization,
|
|
atomic rollback, failure recovery, compatibility, and complete cross-project proof before code is
|
|
written. It must not add an MCP application tool.
|
|
|
|
## Proof
|
|
|
|
- The MCP protocol test asserts the exact tool list and rejects any tool name containing `apply`,
|
|
`commit`, `push`, `deploy`, `publish`, or `shell`.
|
|
- Proposal and adapter tests prove canonical source bytes remain unchanged during create, validate,
|
|
diff, preview, conflict, and stale-source operations.
|
|
- DFG-8 completed a real reviewed proposal through manual integration and the Worldforge canonical
|
|
builder without an application command.
|