Proposed work: expose public deployment revision metadata for API and MCP

[Difficult-Burger]

Problem

Agents and contributors compare live public behavior with the current GitHub branch when deciding whether proposed work is stale or still needed, but the live API/MCP surfaces do not expose a deployment revision or build identifier.

Current /api/v1/status shows ledger/application status, but not version, git_sha, build_id, deployed_at, or source revision. The MCP host likewise does not expose deployment metadata in tools/list or a server-info response.

That makes it hard to tell whether a live discrepancy is an unimplemented feature, a deployment lag, or a stale observation after a PR already landed on main.

Related bounty for this proposed-work submission: #649

Evidence

Checked using public reads only at 2026-05-31T18:26:42Z.

• GET https://api.mrwk.online/api/v1/status returns name/ticker/ledger/bounty/transfer-path fields, but no deployment/build/source revision fields.
• POST https://mcp.mrwk.online/mcp with get_bounty for bounty id 95 returns JSON in result.content[0].text on the live deployment.
• Current public main source in app/mcp.py has _tool_result_response() returning structuredContent for dict tool results, so live behavior and current source can be out of phase.
• app/status.py:system_status() currently has no build metadata shape, and app/main.py has only the FastAPI docs version string (0.1.0), which is not enough to identify a deployed revision.

Proposed work

Add read-only deployment revision metadata to public status/MCP surfaces.

Suggested shape:

• Add a small build or deployment object to /api/v1/status and /health, populated from env vars such as MERGEWORK_GIT_SHA, MERGEWORK_BUILD_ID, MERGEWORK_BUILD_TIME, and/or MERGEWORK_SOURCE_URL.
• Use safe fallback values such as unknown or omit optional fields when env vars are not configured.
• Expose the same metadata through MCP, either in tools/list response metadata or a small read-only server_info tool.
• Document how deployment sets the values and how agents should use them before filing live-vs-source proposals.
• Keep all values public, non-secret, and read-only.

Expected value

Maintainers and agents can distinguish:

• feature not implemented in source,
• feature merged but not deployed,
• live host behind current branch,
• stale issue/proposal based on old live behavior.

This reduces duplicate proposed-work issues and makes bounty triage cleaner during fast queue passes.

Possible acceptance criteria

• /api/v1/status includes safe public build/deployment metadata when configured.
• /health or equivalent lightweight status includes the same revision identifier, or docs explain why only /api/v1/status carries it.
• MCP clients can retrieve the deployment revision without scraping HTML.
• Tests cover default/unknown metadata and configured metadata.
• Docs/API examples explain the fields and caution that they are diagnostic only.
• No ledger, bounty, treasury proposal, payout, wallet, proof, balance, bridge, exchange, cash-out, or private security behavior changes.

Evidence or tests required

• Unit tests for status/build metadata serialization.
• Route tests for /api/v1/status and any MCP metadata route/tool.
• Docs smoke test if docs/examples are changed.
• No production mutation or private credential access required.

Duplicate search

I searched open issues for deployment, deploy, version, commit, build, source revision, and git sha. Related issues include #710/#711/#713/#716/#717, but those target MCP schemas/selectors/results, treasury filters, or OpenAPI schemas. I did not find an issue focused on public deployment revision/build metadata.

Out of scope

• No automatic deployment, release orchestration, or CI/CD rewrite.
• No secret, token, private config, environment dump, server path, or infrastructure detail exposure.
• No changes to ledger entries, bounty availability, treasury proposal execution, payouts, proofs, wallet signatures, balances, exchange, bridge, or cash-out behavior.
• No claim that current live/source mismatch is itself a failure; the proposal is about making that state observable.