MENSARA.AI · A GOVERNED MIND, IN YOUR ACCOUNT
Sign in
Mensara Create account

MENSARA.AI · KNOW WHAT AN ASSISTANT MAY READ OR CHANGE · AGENT VIEW · TEXT/MARKDOWN

# Read and proposal procedure

Discover the authenticated principal and reachable zones first. Read checks principal and granted target before content. A generic authorization denial is a stopping condition; do not reveal or infer target content.

`propose_write` requires propose scope and evaluates both propose and read grants. Read authority alone is insufficient. Use `check_write` before a proposed edit when authorized: it lands no proposed content but can emit a receipt. `ok=true, verdict=fail` means the dry run completed with a failure.

**Template only — use an actual permitted target, current revision, and zone contract.**

```
change = {"path":"<permitted target>","op":"edit","anchor":"<existing heading>","mode":"replace_section","content":"<replacement section>","base_sha":"<verified current revision>"}
check_write({"changes":[change]})
If the check actually passes and this edit is authorized, propose_write({"changes":[change],"rationale":"<reason for change>"})
```

Stop on denial or stale-base. A structural rejection is `ok=false` with its specific reason where supplied; it differs from generic denial. On admission, inspect `proposal_id`, `status`, `branch`, and files. `held` is pending disposition, potentially with degraded bookkeeping fields. `applied` is reported only when governed inline policy returns that status and a commit when present. For an unknown outcome, inspect existing proposal state before considering retry; no broad idempotency guarantee is established.

Captured synthetic in-process fixtures observed a stale check as `ok=true, verdict=fail, reason=stale-base` and a proposal as `ok=true, status=held` with `proposal_id` and `branch`. They are not MCP transport outputs and do not demonstrate approval.

The edit template is incomplete until a valid base token is available. The write gate accepts the target's Git HEAD blob token, or an authorized memory entry's SHA-256 revision. An ordinary read is not shown to return a base token. Do not invent one, hash arbitrary served content, or treat every content hash as interchangeable. Token acquisition for an ordinary account-note edit remains an unverified setup step.

Report `queue_bridge=failed` or `receipt=pending` when present: a held record alone does not prove it is visible to the reviewer or fully receipted. Do not resubmit a landed proposal to repair bookkeeping. On an unknown write outcome, inspect the existing proposal state before considering a retry.

## A tested create, without a base-token assumption

The following arguments were passed to the released Gateway in a temporary synthetic Mind with read and propose scope for `notes`. They are **not a complete MCP client transcript** and `notes` is a fixture path, not a customer default.

```json
{"changes":[{"op":"create","path":"notes/new.md","content":"---\ntitle: Synthetic account update\n---\nThe next check-in is Tuesday.\n"}]}
```

The fixture's `check_write` returned a passing verdict. A separate `propose_write` with those same changes and rationale `Synthetic documentation test` returned `status=held`. The new file was absent from the current working tree afterward. This demonstrates a held create, not an approved edit or an applied customer change.

For a stale change, the operation matters: `check_write` can return `ok=true`, `verdict=fail`, `reason=stale-base`; a rejected `propose_write` uses `ok=false` and `error=stale-base`. Neither is a held proposal.

## Continue

[Current memory and evidence](/how-it-works/current-and-evidence)

[Generated tool input reference](/how-it-works/tool-inputs.md)