Observed 2026-10-15 UTC against mechanical-turk, authenticated as run-c1740c5d. Requested by Jason: "can you sync and express any feature needs?" Scope: a documentation-only working branch; no trunk, release, run, or hosting changes.

Confirmed working

• ocx_status identifies the MCP caller and reports check-in capability.
• ocx_commit_and_sync_guide gives a credential-free standalone-bundle workflow.
• ocx_sync with only a branch returns pushed: [] successfully (a no-op, not proof of transport).
• An isolated anonymous Fossil clone reads current trunk at fa696a9744dd8ece5d81e67c647e47a025c2002f38ee374d4b285f4ebb510185.

Required for reliable trunk-base sync and authenticated receipt verification

1. Make trunk-base pull-bundle responses reliable, with actionable errors. Two real calls to ocx_sync(branch="agent/sync-feature-needs-20261015", have="fa696a9744dd8ece5d81e67c647e47a025c2002f38ee374d4b285f4ebb510185") returned MCP -32603: Internal error. The equivalent dry-run succeeded and listed pull_and_export. Return a valid bundle or a structured failure with the failing stage and safe diagnostic detail. The root cause is unconfirmed; small-branch pull and push-only sync succeed (see completed checks below). Payload size or historical content may matter, but neither is established.
2. Route receipt reads to the served repository from a remote clone context. ocx_receipt(artifacts=<the trunk hash above>) stops with INVALID_ARGUMENT, explaining that the MCP checkout is a clone without the release hook and asking for served-host CLI or web access. The exposed receipt schema provides no repository selector. A narrow authenticated receipt proxy or supported server-side routing would let agents verify receipt without broader host access. Anonymous clone readback can verify artifact presence, but not the authenticated sender's server receipt.

Convenience and observability improvements

• Report operation-specific elapsed time: successive quick status/guide/sync responses reported growing took_ms values around 544,000–603,000 despite individual calls returning within seconds. This appears cumulative; document the meaning or measure per call so timeout diagnosis is useful.
• Return published check-in IDs and verified document/check-in links with sync results, and clearly separate accepted upload, server receipt, pull export, and hosted-page availability. These are distinct outcomes.

No broad agent-tool or additional release/admin permissions are needed for this workflow. Keep the branch-only, structured-commit, no-login-key approach.

Verification for this note

test -s docs/ocx-mcp-feature-needs-2026-10-15.md

Completed checks for the initial version of this note, check-in cdd25dc188cdf6b5aec968a1e61229f9a15c177435d2217aa853a519bd3e7e47:

• Push-only ocx_sync returned the new check-in in pushed.
• A fresh anonymous clone contained the check-in; extracted note bytes matched.
• ocx_sync(have=<that new check-in>) returned a 27,308-character base64 bundle.
• Decoding and fossil bundle import pulled.bundle --publish succeeded.

Thus a small-note round trip works. The trunk-base pull failure and remote receipt routing remain specific gaps. This documentation update is verified separately after publication. No workshop hosting change or availability claim is implied by repository synchronization.

Wiki navigation and unversioned images

Added 2026-10-15 UTC at Jason's request to add these needs to this request. Jason keeps large images as Fossil unversioned files and wants reviewable work linked from the repository wiki. These are separate publication surfaces from versioned check-ins; a branch bundle alone does not establish either outcome.

Live MCP inspection at 02:03 UTC still advertises no wiki or unversioned-file operations. ocx_status reports caller run-c1740c5d with capabilities gio24jrzh, including check-in i but not wiki-write k. Tool availability and Fossil permission are distinct requirements; this request does not authorize silently expanding permissions.

1. Read and update an existing wiki page safely. Provide a read operation returning the page name, complete source, content format, and revision ID. An update should accept an expected revision, reject a stale revision before overwriting another edit, and preserve unrelated page content. For this workflow, add links to the presentation, notes, and stories on the existing landing page rather than replacing it. Require the appropriate wiki-write capability k; check-in i alone is not wiki-write authorization. Return the new wiki artifact/revision and served page URL, then support readback of the stored source so the caller can verify both retained content and new links. If page creation is offered separately, distinguish its permissions from editing an existing page. A narrow wiki operation is sufficient; no general shell or administration tool is requested.

2. List, upload, and synchronize unversioned assets. Provide a listing with asset path, size, timestamp, and content digest; an upload operation with an explicit destination path and expected previous digest (or expected absence); and unversioned synchronization to the served repository. Reject an unexpected overwrite rather than silently replacing a newer image. Report the permissions required for each stage without automatically granting them. Keep binary bytes out of versioned check-ins and avoid embedding large image data in HTML. Return the served /uv/... URL, digest, and separate outcomes for local storage, remote synchronization, and hosted-file verification. Verify the remote bytes against the intended digest before claiming success; ordinary check-in sync or a successful local upload is not sufficient.

For publication, versioned decks should reference these unversioned asset URLs, and the wiki should link to the resulting review pages. This addition requests support only: it neither moves existing images nor edits the wiki. Existing versioned images need an explicitly scoped migration, not an incidental deletion or rewrite while adding these capabilities.