[Frontend][Review] Applied decision record shows the decision actor as a raw user GUID

[Chris0Jeky]

What happened

Found by the 2026-08-29 exploratory acceptance test of the published v0.2.0 build (headless, isolated, live OpenAI at the shipped default gpt-5.6-luna), run under the maintainer's overnight authorization. Full agent report is in the session; screenshots exist locally.

The read-only applied record renders DECISION ACTOR 6bdb48d8-f866-… — the acting user's GUID — instead of the username/display name.

Acceptance

• The applied record shows the actor's display name (with the id available on hover/tooltip if useful), consistent with the audit-log presentation elsewhere.
• Agent/API-key actors render their agent/key name, not a GUID.

[Chris0Jeky]

Prepared PR #2521 with a narrow backend/frontend contract fix: proposal responses now include a server-resolved decidedByUserName, and the applied read-only record renders that name or a localized Not recorded fallback rather than the opaque GUID.

The current proposal lifecycle stores only the deciding user ID. API-key and agent-specific actor identities are not separately persisted or supplied to the approval/rejection contract, so that part of the acceptance remains a follow-up contract gap; this PR deliberately does not guess an actor kind or expose the ID.

Local proof is green: 149 Application tests, 56 API tests, 4 focused frontend tests, typecheck, scoped ESLint, and diff hygiene. PR: #2521

[Chris0Jeky]

PR #2521 is merged as 245886709313f0e0984b5dc1009fcfdf91515864 and completes the user-actor portion of this issue: applied records now render the server-resolved username and use Not recorded when legacy metadata cannot resolve, never the raw GUID. Application/API/frontend regressions and the full hosted matrix passed.

I am leaving this issue open for the second acceptance item. The current proposal lifecycle persists only DecidedByUserId and approval/rejection receives only the authenticated user GUID; it has no persisted actor-kind/name contract for agent or API-key decisions. Implementing that requires a separate schema/authorship design rather than guessing a name from the owner user or exposing an opaque ID. The merged PR documents this boundary and keeps unsupported cases safe.

[Chris0Jeky]

Additional live-state evidence for the remaining acceptance item: Taskdeck's current trust contract explicitly keeps approval human-only (ADR-0003/GP-06), the MCP surface deliberately exposes no approve/apply tool, and API-key authentication is currently scoped to MCP transport rather than the REST proposal decision endpoints. There is therefore no supported agent/API-key decision path whose name can be rendered today. The smallest correct follow-up is a separately designed and gated actor contract: persist an immutable actor kind/id/name snapshot at decision time, define which non-human actor is authorized to decide, and add its auth and UI/API coverage. I am not deriving an agent/key name from the owning user ID, because that would be ambiguous and misattribute the approval.