[peppescg]

Summary

This is the memory fact detail's Proposal row from the Studio alignment (#2210), a follow-up to #1854 (#2222). It's the top of a GitHub stack: #2225 → #2226 → #2228 → this PR. Review and merge from the bottom.

The daemon already reports which learning proposal wrote a memory revision (UserModelRevision.source_proposal_id), but Studio's BFF dropped it. The BFF now maps it, the memory revision contract carries it, and the fact detail shows the prototype's Proposal row when it's set.

What changed

• Contract (apps/contracts/src/schemas/knowledge.ts): memoryRevisionSchema gains sourceProposalId: z.string(), an empty string when no proposal wrote the revision. This is the same shape as sourceSessionId. openapi.json and types.gen.ts are regenerated with task studio:generate; nothing else in the contract changes.
• BFF (apps/server/src/mecatl/knowledge.ts): memoryRevisionFromSdk() maps sourceProposalId from the SDK's UserModelRevision, for the current revision and for every history entry.
• UI (apps/web/src/features/memory/memory-fact-detail.tsx): the prototype's Proposal row, between Source session and Updated. The label is "Proposal", the value is the proposal id in monospace, and it links to Settings → Learning (/workspace/settings/learning) with the same hover:underline link as Source session. The row is absent when the id is empty.

Visible change

A fact written by a learning proposal gets one more row in Details, Proposal, with the proposal id. The rows below it move down by one row. A fact with no proposal looks exactly as before.

Differences from the prototype

None for the row itself: same label, position, monospace value, link styling, and link target (/workspace/settings/learning) as stack-08's memory-fact-detail.tsx.

• Link target: Studio has no route that addresses one proposal, so, like the prototype, the row links to the Learning settings section rather than the proposal. When Studio learning: proposal queue, evidence, and chat reflection #1855 or a later change adds a per-proposal route, the link should point there.

No regression

Pinning tests

2e9fd6256 was committed first, alone, and passes on #2225's head (db98c3768) and on this branch:

• server/src/mecatl/knowledge.test.ts, "maps a memory revision's provenance for the current value and its history": an exact toEqual of what getMemory maps from an SDK revision, for the current value and one history entry, plus the request sent to the SDK. There was no adapter test for getMemory before.
• web/src/features/memory/memory-fact-detail.test.tsx, "orders the Details rows key first and the update time last": the exact row labels, in order, for a fact with a source session.

Modified tests

• The pinning adapter test's expected objects each gain sourceProposalId ("proposal-7" for the current revision, "" for the history entry). The test was written to catch fields the mapping drops, and now it also checks the new field. No expectation was removed.
• The fact detail test's detail() fixture gains sourceProposalId: "" on each revision, which the contract type now requires. No assertion changes.
• The route test's fake getMemory returns sourceProposalId: "proposal-7", which the type now requires.

New tests

• Route and contract (server/src/routes/knowledge.test.ts): GET /api/v1/user-memory/{key} serves sourceProposalId, the body round-trips through memoryDetailResponseSchema, an empty string is accepted, and a revision without the field is rejected.
• Fact detail: the Proposal row links proposal-7 to /workspace/settings/learning in monospace, between Source session and Updated; and without a proposal there is no Proposal row.
• Each new test fails without the change. With the mapping and the schema field removed, the adapter and route tests fail; with the row disabled, the fact detail test fails.

The mecated --mock integration test isn't extended: its memory coverage reads the list and a missing key's 404, not revision fields.

Gate counts

Gate	#2225 (db98c3768)	This branch
Biome	408 files	408 files
Typecheck, generated-check	clean	clean
Server Vitest	24 files / 187 tests	24 files / 189 tests
Web Vitest	123 files / 769 tests	123 files / 772 tests
task studio:browser (desktop + mobile Chromium)	54 passed	54 passed

Screenshots

Captured with a throwaway Playwright journey (Chromium, not committed) with offline BFF routes, a fixed clock (2026-09-25 12:30 UTC), Europe/Rome, and en-US, at desktop 1280×800 and mobile 390×844, in light and dark. Both trees get the same BFF responses, including sourceProposalId; the before tree ignores it. Before is #2225's head (db98c3768), after is this PR's head (299a1b3). They were captured before the stack was linearised onto #2228. That rebase was conflict-free, and neither #2226 nor #2228 touches the memory fact detail. The gates were rerun on the rebased head. Each tree was captured twice and the two runs matched pixel for pixel. Every pair was pixel-compared; red boxes mark the regions that differ. Desktop composites are downscaled to 1600px wide.

Fact written by a learning proposal

Intended change: a Proposal row between Source session and Updated, the proposal id in monospace, linking to Settings → Learning. Everything below it moves down one row.

Dark and mobile

Desktop, dark:

Mobile, light:

Mobile, dark:

Fact with no proposal

No change: the revision's sourceProposalId is empty, so there is no Proposal row. Before and after are identical pixel for pixel.

Dark and mobile

Desktop, dark:

Mobile, light:

Mobile, dark:

Re-verification (2026-10-11)

Re-verified at this head: no change needed.

Closes #2223

🤖 Generated with Claude Code

[kantord]

Post-merge review follow-ups for this PR. No blockers or regressions found. Items worth tracking were filed here:

• Studio: memory fact 'Proposal' link is a dead end #2304 (under Studio: achieve stable end user experience with reasonable behavior #2302): the memory fact "Proposal" link opens Settings > Learning, which usually does not contain that proposal. The prototype has the same flaw.

Other candidate findings were checked and dropped as not worth tracking.

Fully or partially written by an AI agent.