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

2.2 KiB
Raw Blame History

Canonical application decision

Status: Superseded by the DocForge 0.13 hash-bound application contract.

Decision

DocForge may apply one isolated changeset to canonical project sources through an explicit, project-bound canonical applier. Application is available through both CLI and MCP. It is never an implicit consequence of validation, diffing, previewing, or rendering.

The generic adapter owns a deterministic Markdown/TOML serializer. Custom adapters must provide a project-owned CanonicalApplier. Core DocForge does not guess how adapter nodes map back to source files.

Authorization

  • CLI requires apply CHANGESET_ID --changeset-hash SHA256 --applier WRITER_ID.
  • MCP registers docforge_apply_changeset only when the server starts with an explicit canonical applier identity and compatible applier implementation.
  • The changeset creator and applier identity must match a configured proposal writer.
  • The exact final changeset hash is required. Any proposal mutation invalidates an earlier approval.

Application boundary

Application revalidates the canonical base, node hashes, graph, permissions, conflicts, target paths, and projection. Generic writes are staged, confined to declared content roots, and rolled back if the result does not reproduce the approved projection. Successful application rebuilds and checks the derived index and regenerates declared render views.

Application does not run project commands, tests, shell operations, Git, deployment, publication, or arbitrary renderers. Those remain with the owning project workflow.

Why the earlier decision changed

The earlier DFG-9 decision preserved manual integration because there was not yet repeated evidence for canonical application. Later multi-project use produced recurring proposal application work, stale-index round trips, and an explicit user requirement for faster approved integration. The new contract addresses the original safety concerns with:

  • exact changeset-hash approval;
  • startup-bound applier identity;
  • project-owned serializers for custom adapters;
  • canonical path and symlink confinement;
  • rollback and semantic round-trip verification;
  • deterministic derived-state refresh; and
  • complete separation from Git, builds, deployment, and publication.