Submission review: the reviewer cannot see the attestations they are approving

[lonelycode]

The contributor-submission flow is one of the strongest features in the product — /portal/submissions/{id} in particular. These are the gaps on the reviewer's side, where the reviewer approves without being shown what they are approving.

C4b — The reviewer cannot see the attestations the submitter accepted

attestations.accepted[{template_id, accepted_at}] is stored and returned by the API.

/admin/submissions/{id} renders Submission Info, Privacy, Support, Resource Configuration, Test Results and Review History — and nothing about what the submitter signed or when.

The entire point of a legal sign-off gate is that the reviewer can see the sign-off. The data is there and never rendered.

Fix: a panel on the review page listing each accepted attestation with its timestamp. This is the difference between an attestation feature and an attestation record.

C4c — "Test Connection" does not test the connection, for tools

POST /submissions/:id/test branches on resource type:

• datasource → genuinely reaches out to the embedding service
• tool → only re-runs ValidateOASSpec server-side and reports "Spec valid — 2 operations"

The button, the label and the result all read as "we called it and it answered". Same button, two different guarantees, and the name promises the stronger one. A reviewer can approve a tool whose server block points nowhere.

Fix: rename per resource type (Validate specification / Test connection), or actually probe the upstream.

C4d — Review History renders User #1

ui/admin-frontend/src/admin/pages/SubmissionReview.js:539

{activity.actor_name || `User #${activity.actor_id}`} — 

Two panels above, the Reviewer field renders Alice correctly (:305 has the same fallback but the name resolves). An audit trail that does not name people is most of the way to not being an audit trail. Also at SubmissionReviewQueue.js:212.

Fix: populate actor_name on activity records.

C4e — Attestation Templates table prints the raw enum

Shows all where the form that created it offered All resource types / Data sources only / Tools only.

C4f — A Tool created from a submission has an empty tool_type

The seeded Weather tool carries "REST"; the submitted one carries "". Both work identically over REST and MCP, but the portal card renders REST · MCP · Community for one and only Community for the other — so a community contribution looks less capable than an identical admin-created tool, which is precisely backwards for a feature whose job is to make contributions first-class.

C4g — The contributions tab says PUBLISHED; the badge on the card says Approved

And "published" is the wrong word either way, since approval publishes nothing (see the permissive-defaults issue, B0).

---

Acceptance

• Review page renders accepted attestations with timestamps
• Test action names the guarantee it actually provides, per resource type
• Review History names people
• Attestation Templates table renders labels, not enum values
• A submitted Tool carries the same tool_type as an equivalent admin-created one
• Contribution status wording is consistent and accurate

From the UX & UI review of the demo set (section C4b–C4g).

[probelabs]

Thank You for This Detailed Submission Review Feedback

Hi @lonelycode. Thank you for this exceptionally clear and well-structured report. You've identified several important gaps in the contributor submission review flow, particularly concerning the information available to the reviewer. This kind of detailed feedback is invaluable.

Summary of Issues

Based on your report, I understand the key issues to be:

1. Missing Attestation Records (C4b): The reviewer cannot see which legal attestations the contributor accepted, which undermines the purpose of the sign-off gate.
2. Misleading "Test Connection" (C4c): The test functionality for tools only validates the spec without checking the actual upstream connection, which is not what the UI implies.
3. Anonymous Review History (C4d): The audit trail renders a generic User #{id} instead of the actor's name, reducing its usefulness.
4. Raw Enum Values in UI (C4e, C4g): Several parts of the UI display raw system values (all, PUBLISHED) instead of user-friendly labels, leading to inconsistency and confusion.
5. Incomplete Tool Metadata (C4f): Tools created via submission are missing the tool_type, making them appear less capable than identical admin-created tools.

Your analysis seems spot-on, and the proposed fixes are logical. The issue with the actor's name in the review history (C4d) appears to be a data propagation problem, as the user's name is available in other components on the same page.

Next Steps

This issue bundles six distinct items. To make the work more manageable and easier to track, the team will likely break this down into smaller, individual issues. Each point you've raised will be reviewed for prioritization.

We appreciate the thoroughness of your review. No further information is needed from you at this time, but we will reach out if any questions arise during development.

References

• api/compliance_handlers.go – Backend handlers for attestations and submissions.
• api/catalogue_handlers.go – API logic for handling catalogue submissions, including tools.

---

Powered by Visor from Probelabs

💡 TIP: You can chat with Visor using /visor ask <your question>

[lonelycode]

All acceptance criteria met across #518, #519 and #522 (all merged). One optional follow-up left — see the bottom before closing.

Done

• C4b — the review page now lists each accepted attestation with its text (resolved from /attestation-templates, falling back to the id) and its timestamp, and says so plainly when none were accepted. The data was stored and already returned by the API; it was simply never rendered, so reviewers approved without ever seeing the legal gate they had configured.
• C4c — the endpoint now reports check_kind / check_label / check_detail, and the button reads Validate specification for tools and Test connection for datasources. Only a datasource ever contacted anything; a tool submission re-ran ValidateOASSpec and reported "Spec valid", under a label promising the stronger guarantee.
• C4d — the cause was not the UI fallback. Every RecordSubmissionActivity call site passed "" for the actor name, and ApproveSubmission built its activity inline with the same omission, so ActorName was empty on all six activity types. Resolved centrally in ResolveActorName.
• C4e — the table and the create form now read from one APPLIES_TO_OPTIONS list, so they cannot drift apart again.
• C4f — also not what it looked like. tool_type was applied via a setPayload inside validateForm, which does not land before handleSave reads payload. Defaults are now applied to the value actually sent.
• C4g — StatusChip exports its label map and MyContributions reads from it, so a tab and the badges beneath it cannot disagree.

The one thing left

• Actually probe a tool's upstream on Test Connection. Currently the button is honest about only validating the spec, which satisfies the acceptance criterion. Genuinely reaching the upstream means an outbound request to a URL taken from user-supplied spec content — the same SSRF surface [High] Add SSRF safeguards to LLM proxy upstream resolution #396 hardened for the LLM proxy — and should get that review before it ships. The handler carries a comment recording this.

Every checklist item on this issue is now met. Happy to close it and open a separate issue for the upstream probe if you would rather not carry it here — say the word.