wdevs/amcs
5
0
Fork 0
Code Issues 5 Pull Requests Actions Packages Projects Releases 1 Wiki Activity

Add an admin UI for browsing and managing AMCS data #11

New Issue
Closed
opened 2026-04-03 11:12:38 +00:00 by sam · 3 comments
sam commented 2026-04-03 11:12:38 +00:00
Member
Copy Link
Copy Source

Summary

Provide an admin interface for inspecting thoughts, projects, links, files, skills, guardrails, and maintenance state without relying only on MCP or direct database access.

Why

An admin UI is listed as a deferred feature in the implementation plan and would improve operability, debugging, and day-to-day maintenance.

Implementation direction

Scope ideas

  • Browse/search thoughts and projects
  • Inspect metadata status, related links, and attachment/file records
  • Trigger maintenance actions such as backfill or metadata retry where appropriate
  • View server/version/config diagnostics that are safe to expose
  • Add authentication/authorization for the UI
  • Include a login screen and authenticated admin session flow
  • Use Svelix form components for CRUD/admin workflows
  • Use Svelix GridlerFull for tabular browsing, filtering, and management views
  • Standardize the frontend/tooling setup around artemis-kit
  • Follow the overall UI and implementation pattern established in origin where practical
  • Decide whether this is server-rendered, SPA, or a lightweight embedded panel

Acceptance criteria

  • Operators can inspect core AMCS entities through a documented UI
  • Access to the interface requires login and authenticated sessions
  • Sensitive actions are authenticated and permissioned
  • Maintenance and diagnostics visibility improve without exposing secrets
  • ResolveSpec is used to expose the admin API required by the UI
  • Svelix components are used for forms and data grids in the admin interface
  • artemis-kit is used as the default JavaScript tooling baseline for the UI
  • The implementation follows the origin project’s approach closely enough to stay consistent where practical
  • UI scope and deployment model are documented

Source

Deferred feature from llm/plan.md: admin UI.

Additional implementation notes:

  • API framework: ResolveSpec
  • UI component library: Svelix (including GridlerFull)
  • Default JavaScript toolchain: artemis-kit
  • Authentication: required login flow
  • Reference implementation style: origin
## Summary Provide an admin interface for inspecting thoughts, projects, links, files, skills, guardrails, and maintenance state without relying only on MCP or direct database access. ## Why An admin UI is listed as a deferred feature in the implementation plan and would improve operability, debugging, and day-to-day maintenance. ## Implementation direction - Use **ResolveSpec** for the API layer that will serve the Svelte UI: https://github.com/bitechdev/ResolveSpec - Use **Svelix** for UI forms and grid components, especially **GridlerFull**: https://git.warky.dev/wdevs/svelix - Use **artemis-kit** as the default JavaScript toolchain: https://git.warky.dev/wdevs/artemis-kit - Include a **login/authentication flow** for the interface - Model the interface and implementation approach similarly to **origin**: https://git.warky.dev/wdevs/origin - Build the admin interface as a Svelte-based UI backed by the ResolveSpec API ## Scope ideas - Browse/search thoughts and projects - Inspect metadata status, related links, and attachment/file records - Trigger maintenance actions such as backfill or metadata retry where appropriate - View server/version/config diagnostics that are safe to expose - Add authentication/authorization for the UI - Include a login screen and authenticated admin session flow - Use Svelix form components for CRUD/admin workflows - Use Svelix GridlerFull for tabular browsing, filtering, and management views - Standardize the frontend/tooling setup around artemis-kit - Follow the overall UI and implementation pattern established in origin where practical - Decide whether this is server-rendered, SPA, or a lightweight embedded panel ## Acceptance criteria - Operators can inspect core AMCS entities through a documented UI - Access to the interface requires login and authenticated sessions - Sensitive actions are authenticated and permissioned - Maintenance and diagnostics visibility improve without exposing secrets - ResolveSpec is used to expose the admin API required by the UI - Svelix components are used for forms and data grids in the admin interface - artemis-kit is used as the default JavaScript tooling baseline for the UI - The implementation follows the origin project’s approach closely enough to stay consistent where practical - UI scope and deployment model are documented ## Source Deferred feature from llm/plan.md: admin UI. Additional implementation notes: - API framework: ResolveSpec - UI component library: Svelix (including GridlerFull) - Default JavaScript toolchain: artemis-kit - Authentication: required login flow - Reference implementation style: origin
sgcommand commented 2026-04-22 21:04:39 +00:00
Member
Copy Link
Copy Source

Progress update: committed the current AMCS UI scaffold as d13902f (feat(ui): add origin-style admin shell scaffold). This pass switches the UI toward an Origin-like admin shell with a login screen, authenticated sidebar layout, dashboard/status page, and Projects as the first module scaffold. It also swaps to published @warkypublic/svelix, adds the missing Sentry/Skeleton dependencies required by that stack, and confirms production build success after rerunning Vite with increased Node heap. Next step: continue by wiring the ResolveSpec OAuth login path properly and turning Projects into the first real admin workflow (list/grid, detail/edit flow, API integration).

Progress update: committed the current AMCS UI scaffold as d13902f (feat(ui): add origin-style admin shell scaffold). This pass switches the UI toward an Origin-like admin shell with a login screen, authenticated sidebar layout, dashboard/status page, and Projects as the first module scaffold. It also swaps to published @warkypublic/svelix, adds the missing Sentry/Skeleton dependencies required by that stack, and confirms production build success after rerunning Vite with increased Node heap. Next step: continue by wiring the ResolveSpec OAuth login path properly and turning Projects into the first real admin workflow (list/grid, detail/edit flow, API integration).
sgcommand commented 2026-04-22 21:12:12 +00:00
Member
Copy Link
Copy Source

Progress update: pushed the next UI pass to main as cd14be0 after rebasing on the latest remote changes. This pass replaces the placeholder form login with a ResolveSpec OAuth flow in the AMCS UI: discovery from /.well-known/oauth-authorization-server, dynamic client registration through /oauth/register, PKCE authorize redirect to /oauth/authorize, callback handling at /oauth/callback, and code exchange against /oauth/token. Build is green after the auth route wiring. Next step is turning Projects from scaffold into a real Origin-style admin workflow with grid/list, detail editing, and API-backed actions.

Progress update: pushed the next UI pass to main as cd14be0 after rebasing on the latest remote changes. This pass replaces the placeholder form login with a ResolveSpec OAuth flow in the AMCS UI: discovery from /.well-known/oauth-authorization-server, dynamic client registration through /oauth/register, PKCE authorize redirect to /oauth/authorize, callback handling at /oauth/callback, and code exchange against /oauth/token. Build is green after the auth route wiring. Next step is turning Projects from scaffold into a real Origin-style admin workflow with grid/list, detail editing, and API-backed actions.
warkanum commented 2026-04-26 21:42:38 +00:00
Owner
Copy Link
Copy Source

I think I nailed it today with the latest commits

I think I nailed it today with the latest commits
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
architecture
debugging
integration
planned
ux
Compat/Breaking
Breaking change that won't be backward compatible
 Kind/Bug
Something is not working
 Kind/Documentation
Documentation changes
 Kind/Enhancement
Improve existing functionality
 Kind/Feature
New functionality
 Kind/Security
This is security issue
 Kind/Testing
Issue or pull request related to testing
Priority
Critical
1
The priority is critical
Priority
High
2
The priority is high
Priority
Low
4
The priority is low
Priority
Medium
3
The priority is medium
Reviewed
Confirmed
1
Issue has been confirmed
Reviewed
Duplicate
2
This issue or pull request already exists
Reviewed
Invalid
3
Invalid issue
Reviewed
Won't Fix
3
This issue won't be fixed
Status
Abandoned
3
Somebody has started to work on this but abandoned work
Status
Blocked
1
Something is blocking this issue or pull request
Status
Need More Info
2
Feedback is required to reproduce issue or to continue work
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
hein (Hein) root sam sgcommand (SG Command) warkanum (Warky)
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: wdevs/amcs#11
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?