Skip to content

Files Changed: adopt engine-owned mutation routes #1079

Description

@jeonghun-jj-lee

Files Changed: adopt engine-owned mutation routes

Important

Problem - Built-in editing tools and direct server file routes use incompatible metadata and lifecycle paths. Some emit diffs, some emit only file lists, and some can mutate without a session-bound provenance record.
Approach - Route engine-owned writes, edits, patches, moves, deletes, implicit parent creation, formatting effects, and direct file APIs through the mutation gate. Shell, MCP, and custom routes emit declared receipts or explicit unknown-operation receipts.
Scope - in: engine tools and server file routes, multi-resource groups, formatter effects, recursive partial outcomes, and opaque tool handling. out: extension, plugin, runner, and UI adoption.
Assumptions - The registry, context, ledger, evidence, and privacy slices are available.

Acceptance Criteria

  • Every engine-owned file mutation uses a registered context and operation group.
  • Multi-file patches, moves, deletes, and formatter side effects publish one receipt per declared resource with partial outcomes where physical work is non-atomic.
  • Newly created implicit parent directories are declared and receipted before creation.
  • Recursive operations preflight their resource budget and either complete with full accounting or deny before mutation.
  • Direct server file APIs cannot mutate session-visible storage without a valid context.
  • Shell, MCP, and custom routes with declared resources produce ordinary receipts; otherwise they produce a dedicated unknown-operation receipt.
  • Existing tool output can remain readable without serving as ownership authority.

Testing Decisions

  • Extend tool and server-route tests for context validation, group lifecycle, moves, deletes, formatting, parent creation, recursive budgets, and opaque fallback.
  • Add integration cases proving a preflight denial or pre-write failure leaves no applied resource receipt, while an execution-time failure preserves declared resource receipts with explicit partial statuses.

Key Decisions

  • Tool metadata becomes presentation detail; the ledger is ownership authority.
  • Physical non-atomicity is represented as explicit partial outcomes rather than hidden rollback assumptions.

Constraints & Invariants

  • No known local engine mutator silently falls back to untracked behavior.
  • No opaque operation fabricates a resource diff.

Prior Art

Deliberation Resolution

  • Every requested action creates an operation group. A preflight denial or failure before the first physical write produces a group with no applied resource receipt; an execution-time failure preserves intent receipts and marks each affected resource applied, failed, or not_started within a partial group.
  • A denial before resource declaration has no resource receipt. A pre-write failure after declaration retains only not_started intent receipts and no applied resource receipt.
  • This slice consumes the generated mutator registry and resource-identity contract from Files Changed: enforce mutation registry, contexts, and resource identity #1077. Moves have source and destination identities, implicit parents are declared before creation, and formatter effects are added as declared resources before commit.
  • Recursive preflight snapshots the enumerated resource set and budget reservation. A concurrent enumeration change or post-preflight failure yields explicit partial outcomes; a preflight budget overflow denies before mutation.
  • Full accounting includes every declared resource with an applied, failed, or not_started execution status; it does not imply that all declared resources completed successfully.
  • A declared-resource opaque tool must submit a complete normalized endpoint set and then uses local receipt semantics. An undeclared or incomplete opaque declaration produces one Unknown Mutation Receipt and cannot produce a resource diff.

Source

Part of #972. Blocked by #1077 and #1078.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

afkImplementable without human interaction

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions