chore(dashboard): remove dead platform_type UI (closes #2811)#2831
Merged
Conversation
Closes #2811. Migration 409 dropped platform_type from agent_registry_metadata when @adcp/client 5.1.0 replaced the concept with specialisms. The dashboard buildConnectForm still rendered three <select name="platform_type*"> selects (one per auth-type field group) and the save handlers still POSTed body.platform_type — the server silently ignored the field. Deletions from server/public/dashboard-agents.html: - Three <label>Platform type<select ...> rows inside buildConnectForm (bearer/basic, oauth, oauth_client_credentials variants). - The 15-entry platformTypes array and its platformTypeOptions join in renderAgentsSection. - buildConnectForm's platformTypeOptions parameter. Both call sites updated. - platformType reads + body.platform_type assignments in the bearer/basic save handler and the OAuth authorize flow's "context already exists" branch. - The OAuth authorize flow's dead second PUT /connect that was sent to "save platform type even if context already exists". Post-delete: buildConnectForm(escapedUrl, agentContextId) — cleaner signature. Save handlers POST only fields the server actually reads. Agent specialism discovery via get_adcp_capabilities replaces the classification the operator used to hand-set. All 16 isolated form tests still pass. Typecheck + HTML JS parse clean. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
5bedfac to
3eb5ec0
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #2811.
Migration 409 dropped `platform_type` from `agent_registry_metadata` when `@adcp/client` 5.1.0 replaced the concept with specialisms. The dashboard still rendered three `` selects and POSTed `body.platform_type`; the server silently ignored the field. Dead UI shipping dead data. What's removed Three `Platform type<select …>` rows in `buildConnectForm` (bearer/basic, oauth, oauth_client_credentials variants). The 15-entry `platformTypes` array and its `platformTypeOptions` join in `renderAgentsSection`. `buildConnectForm`'s `platformTypeOptions` parameter; both call sites updated (post-change signature: `buildConnectForm(escapedUrl, agentContextId)`). `platformType` reads + `body.platform_type = …` in the bearer/basic save handler and the OAuth authorize flow. The OAuth authorize flow's dead second `PUT /connect` that was sent purely to "save platform type even if context already exists." Agent specialism discovery via `get_adcp_capabilities` replaces the classification the operator used to hand-set. Verification [x] All 16 isolated form tests still pass on the slimmer signature. [x] `npm run typecheck` clean. [x] HTML JS parse clean. [x] Grep confirms no remaining `platform_type` references outside historical migrations (331/342/409 — immutable, intentional). 🤖 Generated with Claude Code