Brokkr/docs/agent-access-cut.md

History (2026-09-30). Superseded by docs/brokkr-adoption-cut.md. The operator unparked agent access, and the adoption map re-derives these cuts against the Codex donor. Read that map; this one is kept only for its rejected paths.

Brokkr Agent Access: Cut Map

Parked (operator, 2026-09-18): "screw it, I'll do any editor shenanigans we need for now." Nothing here is started. The immediate consumer (rigging a scene in Aetheria, F:\Projects\Aetheria\docs\shield-panel-cut.md Cut 4) is the operator's hands instead. Unpark this when editor work becomes repetitive enough to be worth six cuts in this repo, or when the CultMesh MCP bridge campaign (F:\Projects\CultLib\src\GameCult.Mesh\docs\mcp-bridge-campaign.md) takes it up. The probe results below keep their value either way: no serve command, a vendored-assembly collision with CultLib, the file-poke path being dead, and no admission at all.

Status: cut map, nothing landed. Ends: an agent process on this box sends a typed brokkr.unity.command_intent.v0 to a live Unity editor, the editor executes it, and the agent reads back brokkr.unity.command_receipt.v0 plus a refreshed brokkr.unity.host_snapshot.v0. Immediate consumer: rigging scenes in F:\Projects\Aetheria (Unity 6000.3.24f1, built-in pipeline).

This is the thin slice under the named CultMesh MCP bridge campaign (F:\Projects\CultLib\src\GameCult.Mesh\docs\mcp-bridge-campaign.md). It is built so the bridge subsumes it: the seam is a typed operation invoke + receipt read over an already-hosted CultNet endpoint, which is exactly what the campaign's "operation binding descriptor" lowers. Nothing here becomes a second description of what Brokkr offers.

Written by Imagination, 2026-09-18, against Brokkr 94b9334, CultLib fa327a0.

What probing established

Names in the repo do not match the machine. These are the measured facts.

The daemon builds and is green, and is not a daemon. cargo build --workspace and cargo test --workspace pass (20 tests, 0.27s), cargo fmt --check clean, against cultcache-rs pinned at CultLib c2a9a6e5 (brokkr-daemon/Cargo.toml:10), which resolves and compiles. brokkr-daemon/src/main.rs:127-141 dispatches exactly four subcommands: provider|smoke, sync-contract, sync-once, sync-loop. There is no serve. README.md:57 tells you to run cargo run -p brokkr-daemon -- serve under the heading "Unity Smoke"; that command exits 2. The process needs no config, no port, no CultMesh node, no credentials and no Odin, because it opens nothing but two files. sync-loop is a polling scheduler over two .ccmp paths, not a service. tools/check.ps1:112 and tools/vendor-cultmesh-unity.ps1:4 both point at E:\Projects\..., a drive this box does not have.

The daemon's write path is the file, not the mesh. MirrorStore::open (brokkr-daemon/src/main.rs:1400-1404) wraps SingleFileMessagePackBackingStore on the Unity .ccmp directly and pushes envelopes into it (:1421-1443). In cultcache-rs (F:\Projects\CultLib\packages\cultcache-rs\src\lib.rs:652-700) that store is whole-file read-modify-write under a sibling .lock held with fs2. So cross-process writes to the file are safe at the file level.

But a file write does not wake the editor. The Unity mirror subscribes to node.Database.Watch<BrokkrUnityCommand>() (surfaces/unity/Packages/com.gamecult.brokkr/Editor/BrokkrCultMeshMirror.cs:44-52), which observes in-process database mutations. Nothing in the package re-pulls the backing store, and Unity's next FlushAsync(soft: true) (:68, :78, :89) rewrites the whole file from memory. An external file poke is therefore both invisible and liable to be clobbered. This is the single most load-bearing finding: the .ccmp-poke option is not viable for live command delivery.

The live path already exists and is a network one. CultMesh.StartNodeAsync forces StartServer = true (F:\Projects\CultLib\src\GameCult.Mesh\CultMesh.cs:596-602) and CultNetLocal.CreateHostAsync starts the host (GameCult.Networking\CultNetLocal.cs:146-163), so the Unity editor is already hosting a CultNet server. A remote CultNetDocumentPutRawMessage is applied into the hosted database by CultNetDatabaseServer.HandlePutAsync (GameCult.Networking\CultNetDatabaseServer.cs:236), which is exactly the mutation the editor's Watch observes. The typed client side of that message exists in C# (CultNetDocumentRegistry.CreateRawDocumentPutMessage at GameCult.Networking\CultNetDocumentRegistry.cs:212; CultNetDatabaseSubscriptionClient.cs:237). cultnet-rs has RUDP, framing, schema discovery and snapshot query, but no evidenced typed document-put client — treat a Rust caller as unproven work, not a swap.

The port is a constant. GameCult.Networking\Server.cs:26: private const int ServerPort = 3075;. Not in CultNetHostOptions (CultNetLocal.cs:13-44), not in CultMeshNodeOptions (CultMesh.cs:20-50). One Unity editor per machine can host a Brokkr mirror. Security is ServerSecurityOptions.Development() by default (CultNetLocal.cs:149).

Command delivery depends on an open window and an off-by-default toggle. The mirror is owned by BrokkrWindow, an EditorWindow. OnEnable hooks EditorApplication.update (BrokkrWindow.cs:102); OnDisable unhooks it and disposes the mirror (:110-114). The drain is OnEditorUpdate (:775-788), gated on autoPollCommands, which defaults to false (BrokkrSettings.cs:23-27), throttled to one command per second, and it dequeues exactly one command per tick (:382-393). So today: no window open, no commands; window open but toggle off, no commands; window closed mid-run, mirror gone. EditorApplication.update also does not tick dependably while the editor is unfocused, which is the normal state when an agent is driving it.

There is no scene save. Every scene-mutating action ends at EditorSceneManager.MarkSceneDirty (BrokkrUnityCommandExecutor.cs:45, 64, 92, 96, 141, 160, 175, 195, 263). Only the asset commands call AssetDatabase.SaveAssets (:219, 240, 367). An agent's whole rig lives in the editor's memory until a human presses Ctrl+S.

Addressing is sound. Object ids are GlobalObjectId.GetGlobalObjectIdSlow(target).ToString() (BrokkrUnitySnapshotBuilder.cs:183-186), carried in the host snapshot and resolved back on execute. Read snapshot, get ids, issue commands: that loop is already coherent.

The Unity package cannot go into Aetheria as-is. It vendors GameCult.Caching.dll, GameCult.Caching.MessagePack.dll, GameCult.Mesh.dll, GameCult.Networking.dll, GameCult.Logging.dll, MessagePack.dll, R3.dll and 20 more into Plugins/CultMesh/. Aetheria already resolves org.gamecult.cultlib at cultlib-unity-v1.0.60 (F:\Projects\Aetheria\Packages\manifest.json:57), whose Runtime/Plugins/ ships the identical assembly names behind a GameCult.CultLib asmdef with overrideReferences: true. Duplicate assembly names are a Unity compile failure, not a warning. The vendored copies are also stale: GameCult.Mesh.dll is 75,776 bytes in Brokkr against 675,840 bytes in cultlib 1.0.60. package.json declares no dependencies at all and pins "unity": "2022.3".

There is no admission. None. No allowlist, no policy, no caller identity, no signature, no dry-run, anywhere in BrokkrUnityCommandExecutor.cs or BrokkrCultMeshMirror.cs. Anything that can reach the endpoint gets createScriptableObject, createPrefabVariant and arbitrary serialized property writes on a live project. The receipt (BrokkrHostSnapshot.cs:215-226) carries commandId, status, message, objectId, observedAt — the executor's own account of what it did. It is evidence, not proof: no requester identity, no before/after, nothing signed.

Ordered cuts

Cut 1. Cut the stale claims

• Repo/branch: Brokkr, agent-access from 94b9334. No dependencies.
• First: none.
• Deletes first: README.md:49-64 (the serve invocation and the file:E:/Projects/... manifest line). tools/check.ps1:112-118 (the E:\Projects\CultLib-main-work Blender probe branch — it is dead on this box and silently skipped, which is worse than absent).
• Keeps and moves: nothing.
• Adds: a README line naming the four real subcommands and saying plainly that brokkr-daemon is a CLI over .ccmp files, not a listening service.
• Per-file changes:
  • README.md:49-64: replace the Unity Smoke section with the real install path from Cut 2 and the real agent path from Cut 5.
  • tools/vendor-cultmesh-unity.ps1:4: $cultLibRoot from E:\Projects\CultLib to a -CultLibRoot parameter defaulting to F:\Projects\CultLib.
  • tools/check.ps1:112: same, parameterized; fail loudly when absent instead of skipping.
• Authority map: Owner: README and tools/ describe the daemon's real CLI surface. Inputs: main.rs:127-141. Outputs: operator-followable commands. Derived state: none. Forbidden writers: docs may not invent subcommands. Shared paths: n/a. Deletion line: every E:\ literal in the repo.
• Verification:
  • tests: tools/check.ps1 runs to completion on this box with no skipped branch.
  • negative: rg -n 'E:\\\\Projects' F:\Projects\Brokkr returns nothing.
  • negative: rg -n 'brokkr-daemon -- serve' returns nothing.

Cut 2. Make the Unity package installable beside CultLib

• Repo/branch: Brokkr, same branch. Depends on nothing; blocks Cut 5's verification.
• First: record Aetheria's resolved hashes from F:\Projects\Aetheria\Packages\packages-lock.json:245-266 so a regression is attributable.
• Deletes first: the entire surfaces/unity/Packages/com.gamecult.brokkr/Plugins/CultMesh/ tree (27 DLLs plus .meta files) and Plugins.meta, Plugins/CultMesh.meta. These are the collision and they are stale.
• Keeps and moves: tools/vendor-cultmesh-unity.ps1 is retired with them; the package stops carrying its own copy of CultLib.
• Adds: a dependencies block in package.json naming org.gamecult.cultlib at the same git tag Aetheria pins, and "unity": "6000.3" only if 2022.3 support is actually abandoned (see Q7).
• Per-file changes:
  • surfaces/unity/Packages/com.gamecult.brokkr/Editor/GameCult.Brokkr.Editor.asmdef:4-9: references ["GameCult.Brokkr", "GameCult.Caching", "GameCult.Mesh", "GameCult.Networking", "R3"] become ["GameCult.Brokkr", "GameCult.CultLib"].
  • surfaces/unity/Packages/com.gamecult.brokkr/Runtime/GameCult.Brokkr.asmdef:4-7: references ["GameCult.Caching", "MessagePack"] become ["GameCult.CultLib"].
  • surfaces/unity/Packages/com.gamecult.brokkr/package.json:5: add "dependencies": {"org.gamecult.cultlib": "https://github.com/GameCult/CultLib.git?path=/unity/org.gamecult.cultlib#cultlib-unity-v1.0.60"}.
  • tools/check.ps1:100-111: the required-DLL assertion inverts — assert the vendored tree is absent and the asmdefs reference GameCult.CultLib.
• Authority map:
  • Owner: org.gamecult.cultlib owns the CultCache/CultNet/CultMesh assemblies in every Unity project. com.gamecult.brokkr owns only Brokkr's document types, editor service, executor and window.
  • Inputs: the host project's resolved CultLib package version.
  • Outputs: GameCult.Brokkr and GameCult.Brokkr.Editor assemblies.
  • Derived state: none.
  • Forbidden writers: the Brokkr package may no longer ship any assembly whose name CultLib also ships.
  • Shared paths: Aetheria and any future host project resolve one CultLib.
  • Deletion line: Plugins/CultMesh/ and the vendoring script, before any asmdef edit.
• Verification:
  • builds: add "com.gamecult.brokkr": "file:F:/Projects/Brokkr/surfaces/unity/Packages/com.gamecult.brokkr" to F:\Projects\Aetheria\Packages\manifest.json, open Unity 6000.3.24f1, and confirm a clean compile with no duplicate-assembly error in Editor.log. This is also the first real test of whether the package's source compiles against cultlib 1.0.60's API at all — the vendored DLLs were an order of magnitude smaller, so drift is likely and StartNodeAsync, CultMeshNodeOptions.EnableDurableShardLogs, CultNetDatabaseOptions.RuntimeId and node.Database.Watch<T>() each need to still exist.
  • negative: packages-lock.json gains com.gamecult.brokkr and nothing else; no new transitive package appears.
  • operator: Unity's Package Manager shows Brokkr with no errors and GameCult > Brokkr opens.

Cut 3. Move command drain off the window

• Repo/branch: Brokkr, same branch. Depends on Cut 2.
• First: none.
• Deletes first: BrokkrWindow.cs:113-114 (mirror disposal in OnDisable), :102/:110 (the EditorApplication.update hook/unhook), :775-788 (OnEditorUpdate), :377-400 region's ownership of dequeue-and-execute, and the private BrokkrCultMeshMirror mirror field at :18.
• Keeps and moves: PollAndExecuteCommand's body moves into the new service unchanged in behaviour except for the batch rule below. The window keeps its buttons, which now call the service.
• Adds: Editor/BrokkrEditorService.cs, [InitializeOnLoad], static, owning one BrokkrCultMeshMirror for the editor's lifetime, hooking EditorApplication.update once, draining all queued commands per tick rather than one per second, and surviving domain reload by re-opening on the static constructor. Gate on an EditorPrefs enable flag (renamed from AutoPollCommands, default still false) so an unattended project does not silently host a mutation endpoint.
• Per-file changes:
  • BrokkrCultMeshMirror.cs:16: the Queue<BrokkrUnityCommand> stays, but the service owns dequeuing. No change to the watch.
  • BrokkrWindow.cs:65-114: OnEnable/OnDisable stop touching the mirror; they read service state for display only.
  • BrokkrSettings.cs:23-27: AutoPollCommands becomes AgentCommandsEnabled, same default false.
• Authority map:
  • Owner: BrokkrEditorService owns mirror lifecycle and command drain.
  • Inputs: AgentCommandsEnabled, CultMeshCachePath, the watch queue.
  • Outputs: executed mutations, brokkr.unity.command_receipt.v0, refreshed brokkr.unity.host_snapshot.v0.
  • Derived state: BrokkrWindow's lastReceipt, lastSnapshot, lastSyncReceipt are display-only. The window is no longer an owner.
  • Forbidden writers: BrokkrWindow.OnDisable may not dispose the mirror; nothing but the service may call TryDequeueCommand.
  • Shared paths: window-button commands, agent-sent commands and daemon sync-once commands all land in the same queue and take the same BrokkrUnityCommandExecutor.Execute path.
  • Deletion line: the window's mirror field and update hook, deleted before the service is wired.
• Verification:
  • builds: Aetheria compiles.
  • operator: enable the flag, close the Brokkr window, send a command, see it execute. That negative — the old path could not do this — is the point of the cut.
  • negative: rg -n 'EditorApplication.update' surfaces/unity matches only BrokkrEditorService.cs.

Cut 4. Make the editor reachable and awake

• Repo/branch: Brokkr, same branch. Depends on Cut 3.
• First: measure it. With the service running, unfocus Unity, send a command from a second process, and time the receipt. If it lands in under a second the unfocused-tick worry is theoretical on Unity 6000.3 and this cut shrinks to endpoint publication alone. Do not build the compensator before the measurement.
• Deletes first: nothing.
• Adds:
  • Runtime/BrokkrEndpoint.cs: brokkr.unity.endpoint.v0 — host, port, projectPath, unityVersion, startedAt, agentCommandsEnabled, process id. Published by the service on start into the mirror at unity/endpoint/current, and written as a plain sibling file <project>/.brokkr/endpoint.cc so an agent can find a live editor without already being connected to it. The file is a discovery pointer, not authority; the document in the mirror is the truth.
  • Only if the measurement demands it: a keep-awake that does not lie about ownership. EditorApplication.update stays the single drain; the addition is a background System.Threading.Timer that calls EditorApplication.QueuePlayerLoopUpdate()/delayCall to force ticks while agentCommandsEnabled is set. The timer schedules; it never executes a command off the main thread.
• Per-file changes: BrokkrEditorService.cs publishes the endpoint on start and clears it on quitting.
• Authority map: Owner: the service owns the endpoint document. Inputs: node.Server port, Application. Outputs: brokkr.unity.endpoint.v0. Derived state: .brokkr/endpoint.cc is a discovery cache; a stale one must be detectable (check pid, refuse on mismatch). Forbidden writers: the agent CLI may read it and must never write it. Deletion line: n/a.
• Verification:
  • operator: with Unity unfocused and a browser in front, an agent command executes within a stated bound; record the measured latency in the doc.
  • negative: kill Unity, and the CLI reports "no live editor" from the pid check rather than hanging on a connect.

Cut 5. brokkr-ctl: the agent's hands

• Repo/branch: Brokkr, same branch. Depends on Cuts 2-4.
• First: none.
• Deletes first: nothing. This is net-new surface and must justify itself: it buys the named capability (an agent process drives a live editor) that no existing owner provides, because brokkr-daemon writes files the editor cannot see and the Unity window is not callable from outside Unity.
• Adds: tools/brokkr-ctl/ — a .NET console project referencing CultLib's GameCult.Mesh/GameCult.Networking projects and Brokkr's document types. Subcommands, all reading .brokkr/endpoint.cc for the target:
  • snapshot [--project PATH] — connect, read unity/host/current, print it.
  • send --action <a> [--target-object-id ID] [--name N] [--component-type T] [--property-path P] [--value V] [--asset-path A] [--parent-object-id P] [--local-position x,y,z] [...] — build a BrokkrUnityCommand, put it at unity/commands/{guid}, then block on the matching unity/receipts/{commandId} with a timeout, print the receipt, exit non-zero on status != accepted.
  • send --file plan.cc — a batch of intents applied in order, stopping at the first failure, printing every receipt. This is what makes scene rigging usable instead of a hundred process launches.
  • watch-receipts — tail receipts. The document types are shared with the Unity package rather than redeclared: the Runtime/ .cs files are compiled into brokkr-ctl by <Compile Include> so there is exactly one definition of brokkr.unity.command_intent.v0.
• Authority map:
  • Owner: brokkr-ctl owns nothing. It is a caller. Unity owns the mutation; the receipt owns the outcome; the snapshot owns editor truth.
  • Inputs: CLI args, .brokkr/endpoint.cc.
  • Outputs: one brokkr.unity.command_intent.v0 per invocation, to the live node over CultNet.
  • Derived state: printed text is telemetry. Exit code is derived from the receipt status, never from "the put succeeded".
  • Forbidden writers: brokkr-ctl must never open the .ccmp file. That path is invisible to a running editor and clobbered by its next flush. It must never write receipts, snapshots or endpoint documents.
  • Shared paths: brokkr-ctl, the Brokkr window's buttons and brokkr-daemon sync-once all produce the same intent document and go through the same executor. No second commit primitive.
  • Deletion line: if brokkr-ctl grows its own policy, its own receipt ledger, or its own idea of editor state, cut it back to a caller.
• Verification — this is the decisive one:
  1. Open F:\Projects\Aetheria in Unity 6000.3.24f1 with the Brokkr package installed. Enable agent commands. Note .brokkr/endpoint.cc.
  2. From a Claude Code session, run brokkr-ctl send --action createGameObject --name BrokkrProofOfLife. Assert: exit 0, receipt status=accepted, receipt objectId is a GlobalObjectId string.
  3. brokkr-ctl send --action attachComponent --target-object-id <that id> --component-type UnityEngine.BoxCollider → accepted.
  4. brokkr-ctl send --action setGameObjectTransform --target-object-id <that id> --local-position 1,2,3 → accepted.
  5. brokkr-ctl snapshot → the returned brokkr.unity.host_snapshot.v0 contains a BrokkrGameObjectSnapshot named BrokkrProofOfLife with localPosition (1.0, 2.0, 3.0) and a BoxCollider in components.
  6. The layer the operator sees: the operator looks at the Unity Hierarchy and the Inspector and confirms the object, the collider and the transform are there, and that the scene shows dirty. A receipt that says accepted while the Hierarchy is empty is the failure this step exists to catch — the executor writes its own receipt, so the receipt alone cannot prove the mutation.
  7. Undo (Ctrl+Z) removes it, proving the Undo.RegisterCreatedObjectUndo path at BrokkrUnityCommandExecutor.cs:43 is real and the operator retains a way out.
  8. Negative: with agent commands disabled, step 2 times out and exits non-zero without mutating anything.

Cut 6. Admission and the save question

• Repo/branch: Brokkr, same branch. Depends on Cut 5.
• First: verify what Server binds. Server.cs:26 fixes the port at 3075 but the bind address was not established in this pass. If it binds 0.0.0.0, every machine on the LAN can currently mutate an open Unity project, and this cut is urgent rather than tidy.
• Deletes first: nothing, because there is nothing. Stated plainly: today admission is absent, not weak.
• Adds:
  • Loopback-only binding for the Brokkr mirror node, or an explicit operator opt-in to bind wider.
  • A BrokkrCommandPolicy consulted by the service before BrokkrUnityCommandExecutor.Execute: an action allowlist and an asset-path prefix allowlist, defaulting to scene mutation permitted and asset-creating actions (createScriptableObject, createPrefabVariant) denied. Denials produce a status=denied receipt, so a refusal is as inspectable as an acceptance.
  • requestedBy on the intent and deniedReason on the receipt, so a receipt says who asked, not only what happened.
  • A saveScene action, gated by the same policy and denied by default (Q4).
• Authority map: Owner: BrokkrCommandPolicy owns admission. Inputs: the intent, EditorPrefs policy. Outputs: permit/deny. Derived state: the receipt's status. Forbidden writers: the executor may not bypass the policy; the window's own buttons go through it too, so operator and agent share one admission path rather than two truths. Deletion line: n/a.
• Verification:
  • negative: a createScriptableObject intent under default policy yields status=denied and creates no asset — verified by AssetDatabase absence, not by the receipt.
  • negative: rg -n 'Execute\(' surfaces/unity shows the policy call on every path into the executor.

Subtraction ledger (estimate)

Cut	Removed	Added	Deps/targets
1	~30 lines docs/scripts, 1 dead branch	~15 lines	—
2	27 DLLs + 27 .meta (~6 MB), 1 script (~55 lines)	~6 lines manifest	−0 packages in Brokkr, +1 UPM dep declared, +1 UPM dep in Aetheria
3	~45 lines from BrokkrWindow.cs	~90 lines (BrokkrEditorService.cs)	—
4	—	~70 lines + 1 document type	+1 schema
5	—	~350 lines	+1 build target (tools/brokkr-ctl, .NET console), +2 project references to CultLib
6	—	~120 lines	—

Net: strongly negative in shipped bytes (the vendored DLL tree dwarfs everything added), net +1 executable target and +2 schemas. The one new target is the whole point of the campaign's gap and is the thing the MCP bridge later wraps rather than replaces. Build budget: cargo build/test --workspace already runs in 24s cold, and nothing here touches the Rust crate. The new .NET target builds GameCult.Mesh + GameCult.Networking from CultLib source — check that cost on first build; if it exceeds a few seconds, reference the packed assemblies instead. Build host is this Windows box and the artifacts run on it, so no cross-platform claim is being made.

Operator forks

Q1 — Where the agent-side tool lives, and in what language. Most blocking: everything after Cut 2 assumes an answer.

• A: tools/brokkr-ctl, a .NET console in this repo, CultNet client over the Unity node's port.
• B: Extend brokkr-daemon in Rust with a send/snapshot subcommand.
• C: No tool; agents poke the .ccmp file.

Recommended: A. C is dead on the evidence — a file write is invisible to the running editor's Watch and gets clobbered by its next flush. B needs a typed document-put client in cultnet-rs that does not exist today; the RUDP and schema primitives are there, so it is buildable, but it is a campaign-sized detour to reach parity with a C# client that already works. A reuses CultNetDocumentRegistry.CreateRawDocumentPutMessage and the same document .cs files Unity compiles, so there is exactly one definition of the intent schema. When the MCP bridge lands in Rust, brokkr-ctl is what it replaces, and the intent/receipt contract it exercised is what the bridge lowers.

Q2 — Does the editor poll or subscribe?

• A: Subscribe. The mirror already does (BrokkrCultMeshMirror.cs:44-52); the bug is that the drain of the subscription queue is window-owned and rate-limited to one command per second.
• B: Add an explicit poll of the backing store.

Recommended: A. B would mean re-pulling the .ccmp in the editor and creating a second delivery path with different semantics — two truths about how a command arrives. Cut 3 fixes the real defect (ownership and batching) without inventing a lane.

Q3 — Unfocused ticking.

• A: Measure first (Cut 4's "First"), and only add a keep-awake timer if the measurement shows a stall.
• B: Add the timer now.
• C: Require the editor focused; document it and move on.

Recommended: A. B is a compensator bought before the symptom is confirmed on Unity 6000.3. C is honest but makes the tool useless for the actual use — an agent drives Unity while the operator is elsewhere.

Q4 — Does scene save become a command?

• A: New saveScene action, denied by default in policy, opt-in per project.
• B: Save stays the operator's, always.

Recommended: A, shipped denied. B is safer today and is what Cut 5's verification assumes, but it means an agent rigging fifty objects leaves all of it in volatile editor memory, and one crash or one mis-clicked "Don't Save" takes the lot. A with a default denial keeps the operator's hand on the switch while making the capability exist and inspectable. If you would rather not have the action in the codebase at all, B is defensible; say so and Cut 6 drops it.

Q5 — MCP server now, or CLI the bridge wraps?

• A: CLI now; the campaign's generic CultMesh MCP bridge wraps or replaces it.
• B: A Brokkr-specific MCP server now.

Recommended: A. The campaign doc is explicit that Brokkr-specific tooling treats the symptom and that the missing organ is general (mcp-bridge-campaign.md, "Brokkr-specific tooling would treat the symptom"). A Brokkr MCP server is exactly the thing the campaign says not to build, and it would have to be deleted. A CLI is a caller — the bridge invokes the same typed operation over the same endpoint, and brokkr-ctl either becomes a thin shim or goes away without anything else moving. It also answers the campaign's own open question ("what a provider must publish before it is usable through the bridge, and whether Brokkr already publishes it") with a worked example: Brokkr publishes the commands and receipts but not the endpoint, which is Cut 4.

Q6 — The hard-coded port 3075 (Server.cs:26).

• A: Accept it; one Brokkr-hosting Unity editor per machine, and the endpoint document says which project owns it.
• B: Push a port option into CultNetHostOptions in CultLib.

Recommended: A for this slice, B as a CultLib follow-up. B is a change to shared substrate every runtime depends on, and it does not belong inside an unblock-the-work cut. A is honest as long as brokkr-ctl refuses clearly when .brokkr/endpoint.cc names a different project than the one asked for — which is worth stating as a requirement, because the silent failure (commands landing in the wrong Unity project) is exactly the class of damage this whole effort exists to stop.

Q7 — Does com.gamecult.brokkr stay self-contained?

• A: Depend on org.gamecult.cultlib; drop the vendored DLLs (Cut 2 as written).
• B: Keep vendoring, and make it installable only in projects without CultLib.

Recommended: A. B cannot serve the immediate consumer at all: Aetheria has CultLib and the assembly names collide. A also ends the staleness — the vendored GameCult.Mesh.dll is a tenth the size of the one Aetheria resolves, which means the package has been compiling against a CultMesh from a different era. Expect Cut 2 to surface real API drift; that is the cut doing its job, not a surprise.