Mission Control Workbench Record Browser and Editor

Superseded by Mission Control UAS Database.

What should we do?

Build a Mission Control UI for browsing and editing the Lantronix workbench records directly in MC, using the existing task list view as the interaction model for the index page. The user should be able to scroll through records in a compact list, click a row to open a dedicated detail page in a new browser tab, edit fields in a human-friendly form, and save changes back to the source JSON records.

This should replace spreadsheet-first review as the main quality-control surface for the current Lantronix/UAS dataset.

Why this needs to exist

The current source-of-truth data is structured well for the system but bad for human review.

Current options are both weak:

• raw JSON files are accurate but painful to scan and edit at scale
• Google Sheets is easy to scan but flattens nested fields poorly and turns arrays, enums, and linked records into ugly text blobs

Pete wants a native Mission Control review surface with this interaction model:

• task-list-style scrolling through all records
• click an item to open a new page in a new tab
• edit details on that page
• save changes directly

Product decision

Phase 1 should be a Lantronix workbench record browser/editor inside Mission Control, not a generic JSON editor and not a new standalone app.

The design should borrow hard from the existing MC tasks experience:

• compact list rows for fast scanning
• filters at the top
• clean detail page for one record at a time
• direct save

Goals

1. Make the current Lantronix dataset easy to review record by record.
2. Preserve the JSON files as source of truth.
3. Hide raw schema complexity behind human-friendly field groupings and controls.
4. Support direct editing and save for the four current record types:

• companies
• products
• customer segments
• evidence sources

1. Let Pete review records in detail without losing list position.

Non-goals

1. Do not build a generic schema-driven editor for any arbitrary dataset in v1.
2. Do not replace the current file-based store.
3. Do not build full multi-user collaboration, comments, or approval workflow in v1.
4. Do not redesign all of Mission Control.
5. Do not block v1 on adding every possible field-level convenience.

Primary user flow

1. Pete opens a new Mission Control section, for example /workbench/lantronix.
2. He sees a compact list view that feels like the current Tasks list view.
3. He filters to companies, products, evidence, or customer segments.
4. He scrolls the list and scans the key fields in each row.
5. He clicks a row title.
6. MC opens a dedicated detail page for that record in a new browser tab.
7. The detail page shows grouped fields, linked records, source links, and editable controls.
8. Pete edits fields and clicks Save changes.
9. MC validates the record, writes back to the underlying JSON file, and confirms the save.
10. Pete returns to the original list tab and keeps reviewing.

Information architecture

New top-level MC section

Add a new section in Mission Control navigation:

• Workbench
• Lantronix Records

Routes

Recommended initial routes:

• /workbench/lantronix
• /workbench/lantronix/companies/[id]
• /workbench/lantronix/products/[id]
• /workbench/lantronix/customer-segments/[id]
• /workbench/lantronix/evidence/[id]

Optional later:

• /workbench/lantronix/new
• /workbench/lantronix/import
• /workbench/lantronix/compare/[idA]/[idB]

UX spec

1. Index page, task-list-style record browser

The list page should reuse the best parts of the current task list view.

Layout

• left-to-right full-width workspace
• sticky filter bar at top
• compact scrollable rows below
• one row per record
• row click opens a new tab to the record detail page

Default row model

Each row should show:

• record type icon and label
• display name
• a short secondary summary line
• key chips / tags relevant to the record type
• last updated date
• warning / low-confidence indicator when relevant

Filters

Top-level filters for v1:

• record type
• search by name / id / URL / title
• concerns_lantronix yes/no, for company records
• evidence confidence
• geography / region
• vertical
• NDAA relevance / sensitivity where applicable
• has validation errors

Sorting

Support:

• updated recently
• alphabetical
• confidence
• concerns_lantronix first

Record-type-specific row previews

Company row

• name
• concerns_lantronix pill
• primary verticals
• ecosystem roles
• NDAA status summary
• short summary preview

Product row

• product name
• company name
• product class
• target segments
• evidence confidence

Customer segment row

• segment name
• vertical
• Lantronix strategic fit
• NDAA sensitivity

Evidence row

• title
• source type
• publisher
• confidence
• verification status
• linked company/product count

2. Detail page, one record per page

This is the core edit surface.

Detail page rules

• opens in a new browser tab from the list view by default
• full-page view, not a modal
• save and cancel controls stay visible
• show source JSON file path, but do not make raw JSON the primary UI
• show related records and outbound links

Header

Top of page should include:

• record title
• record type
• source file path
• last updated timestamp
• save state: saved / unsaved changes / validation errors
• buttons:
• Save changes
• Revert
• Open raw JSON
• Open source URL, when applicable

3. Editable form design by record type

The editor should use grouped sections with human-friendly controls.

Company detail page

Recommended sections:

Identity

• name
• website
• headquarters
• country code
• region
• year founded

Relevance and positioning

• concerns_lantronix toggle
• summary
• market positioning note
• platform domains
• key use cases

Business profile

• ecosystem roles
• service capabilities
• primary verticals
• cross-cutting tags
• company scale fields

Customer and compliance

• target customer segment ids, shown as selectable linked records
• NDAA profile
• channel model

Evidence and relationships

• linked source ids
• linked product ids
• quick links to related detail pages

Product detail page

Sections:

• identity
• company linkage
• product class
• platform domains
• target customer segments
• technical positioning summary
• status
• source ids
• notes

Customer segment detail page

Sections:

• segment identity
• vertical
• buyer personas
• jobs to be done
• buying criteria
• geography focus
• NDAA sensitivity
• strategic fit for Lantronix
• source ids

Evidence detail page

Sections:

• source identity
• URL / publisher
• captured date
• confidence
• verification status
• geography scope
• NDAA relevance
• report relevance
• applies_to links
• claim summary
• notes

Editing model

Human-friendly controls first

Use controls that match field type:

• text input for short strings
• textarea for summaries and notes
• select for enums
• multi-select chips for arrays of enums
• linked-record pickers for ids that reference other records
• toggle for booleans
• date input for captured dates

Raw JSON fallback

Each detail page should include an Open raw JSON action for advanced inspection.

That action is for trust and edge cases, not the primary editing path.

Save behavior

• edits stay local on the page until Save
• Save validates before write
• if validation passes, write back to the original JSON file
• if validation fails, show field-level errors and do not save
• if the file changed on disk since load, show a conflict warning and require reload or override flow

Validation rules

V1 validation

Use the existing JSON schemas as the source of validation truth.

At minimum:

• required fields enforced
• enum values enforced
• id formats enforced
• URL fields validated
• array uniqueness preserved where required

Validation UX

• inline field errors where possible
• page-level error summary at top
• warning banner when a save fails
• “saved successfully” confirmation when write succeeds

Data model and storage

Source of truth

Keep the current file store exactly where it is:

• data/lantronix-uas-workbench-phase1/records/companies/
• data/lantronix-uas-workbench-phase1/records/products/
• data/lantronix-uas-workbench-phase1/records/customer-segments/
• data/lantronix-uas-workbench-phase1/records/evidence/

Read/write model

Mission Control should read from and write to these files through server routes and store helpers, not by direct client-side file access.

Recommended helpers:

• lib/lantronix-records.ts
• lib/lantronix-record-validation.ts

Recommended API routes:

• GET /api/workbench/lantronix/records
• GET /api/workbench/lantronix/records/[type]/[id]
• PUT /api/workbench/lantronix/records/[type]/[id]

Optional later:

• POST /api/workbench/lantronix/records/[type]
• DELETE /api/workbench/lantronix/records/[type]/[id]

Reuse of existing MC patterns

This should intentionally reuse existing Mission Control UI patterns rather than invent a second design language.

Strong reuse candidates:

• app/(app)/tasks/page.tsx
• components/tasks/TasksWorkspace.tsx
• components/tasks/TaskListView.tsx
• components/tasks/TaskEditorModal.tsx

Specifically:

• the list page should borrow row density, scanning rhythm, and filter posture from TaskListView
• the detail page should reuse the clean editing posture from TaskEditorModal, but as a full page instead of a modal
• do not copy the Kanban board paradigm, use the list paradigm

Record detail navigation behavior

Pete explicitly wants detail to open in a new tab.

V1 behavior:

• primary row click target is the record title link
• title link opens in a new browser tab
• optional secondary icon for “open in current tab” can exist, but new-tab open is the default interaction

Reason:

• preserve scanning place in the list view
• make QC feel like triage, not serial modal editing

Scope for v1

Included

• list page for all Lantronix records
• filters and search
• dedicated detail pages by record type
• edit and save
• schema validation
• related-record links
• raw JSON escape hatch

Excluded from v1

• inline edit in the list view
• bulk edit
• import/export workflows
• comments / annotations / review assignments
• edit history UI
• generic schema builder
• support for non-Lantronix datasets

Acceptance criteria

1. Pete can open /workbench/lantronix and scroll all current records in one compact list interface.
2. He can filter to companies, products, customer segments, or evidence.
3. Clicking a record opens a dedicated detail page in a new tab.
4. The detail page shows grouped, human-friendly sections instead of raw JSON blobs.
5. Pete can edit a company record, save it, refresh the page, and see the persisted change.
6. Invalid edits are blocked with clear errors.
7. Linked relationships are visible and navigable.
8. The experience is materially better than the Google Sheet for QC of nested fields and linked records.

Implementation phases

Phase 1

Ship the list page plus company detail editor.

Why:

• company records carry most of the QC value
• this gets the main workflow live fastest

Phase 2

Add product, customer segment, and evidence detail editors.

Phase 3

Add quality-of-life features:

• validation summary view
• unsaved changes warning on navigation
• related-record side panel
• simple bulk actions

Risks

1. Nested arrays and linked ids can get awkward if the editor tries to be too generic.
2. File-write conflicts could happen if multiple edits land close together.
3. If we overbuild schema abstraction first, this becomes a framework project instead of a useful tool.

Recommendation

Build this as a Lantronix-specific Mission Control workbench editor first, using the existing task list view as the pattern library. Start with the company list and company detail page, get editing and save reliable, then extend the same pattern to the other record types.

That gives Pete the QC surface he actually wants without turning this into a generic admin platform project.

Open questions

1. Should list rows show one mixed list for all record types by default, or separate tabs with “All records” as an option?
2. Should detail pages support next/previous keyboard navigation back into the list review flow?
3. Do we want a lightweight QC flag later, or keep v1 strictly limited to existing source fields?