FabledGrimoire

GET /api/plugin/write-scope answers the plugin's fence. The session's project
comes from repo / project_id, as every plugin endpoint reads it. The act is
either:
- a directory (target_repo / target_project_id), for a file edit or a git
  command; or
- an MCP call (tool, plus input: the call's short arguments).

It returns allowed, the other projects the act would change, and the reason
the operator is asked. It is a GET so a read-scoped key still fences file
edits and git.

services/write_scope.WRITE_TARGETS lists every write tool with the arguments
that locate its write: a project id, or a task, note, milestone, System, rule,
relation, trash batch, repo or family decision, each traced to its project. A
write that lands in no project (install settings, user-level records, the
judgments a session is asked for anywhere) has an empty entry. The one
cross-project write allowed is create_task(kind="issue") as a new, unplanned,
open issue. A project the caller cannot read is never named.

tests/test_write_scope.py:
- requires an entry for every write tool;
- requires every declared argument to exist on the tool;
- refuses a locating argument (project_id, task_id, milestone_id and the
  rest) that a write tool takes without declaring it.

The integration test traces each locator from real rows.

Milestone 583, step 2.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

2026-11-04 21:39:03 -05:00

api-keys-and-mcp.md

rename(547): the repo is FabledGrimoire, and no stray "scribe" is left

2026-10-22 13:29:00 -04:00

api-reference.md

feat(6854): the server says which project a pending act would change, and whether this session may do it

2026-11-04 21:39:03 -05:00

architecture.md

feat(6849): the command-line restore uses the same rollback, and the docs say how restore works now

2026-11-04 20:08:31 -05:00

backups.md

feat(6849): the command-line restore uses the same rollback, and the docs say how restore works now