Repository navigation
Build Mnehmos Ops: authenticated admin + agent API + Kanban control plane #5
Description
Goal
Turn the main Mnehmos Astro site into the operational control plane for the entire Mnehmos ecosystem.
The public site remains the public-facing portfolio/catalog, but an authenticated administrator area and agent-facing API become the shared system of record for distribution, marketing, coding, releases, and tool-specific workspaces.
Product model
Public surface
/public Mnehmos site/projectspublic project catalog/distributionpublic/read-only distribution status where appropriate- package/install/registry links generated from canonical tool metadata
Admin surface
/adminauthenticated overview/admin/boardKanban board/admin/toolstool/repo distribution matrix/admin/workspacesagent workspaces and active assignments/admin/agentsregistered agents, scopes, status, last heartbeat/admin/releasesrelease/distribution queue/admin/marketinglaunch assets, campaigns, channels, metrics/admin/activityappend-only event/activity feed
KISS architecture
Use Astro in server/SSR mode rather than introducing a separate frontend application.
Suggested first implementation:
- Astro SSR/API routes
- Postgres-backed persistence (Supabase is acceptable and keeps auth/database simple)
- Admin authentication restricted to the owner account
- scoped API keys/service tokens for agents
- one database/schema serving dashboard + API
- deploy to a host that supports Astro SSR/API routes rather than static-only GitHub Pages
Keep the public frontend and operational backend in this repository until scale justifies separation.
Agent API
Create a versioned API surface under /api/v1.
Minimum resources:
GET /toolsGET /tools/:idGET /tasksPOST /tasksPATCH /tasks/:idPOST /tasks/:id/claimPOST /tasks/:id/eventsGET /workspacesPOST /workspacesPATCH /workspaces/:idGET /agentsPOST /agents/heartbeatGET /releasesPOST /releasesGET /campaignsPOST /campaignsPOST /artifactsGET /activity
All write endpoints require scoped agent credentials or administrator auth.
Kanban data model
Tasks should not be generic sticky notes. Every card should be machine-actionable.
Required task fields:
- id
- title
- description / acceptance criteria
- lane/status
- priority
- domain:
coding | distribution | marketing | docs | release | research | operations - tool/repo id
- GitHub issue/PR links
- assigned agent(s)
- required capabilities/scopes
- dependencies / blocked_by
- workspace id
- created/updated timestamps
- result/artifact links
- structured event history
Default lanes:
Backlog -> Ready -> Claimed -> In Progress -> Review -> Blocked -> Done
Agents must claim work atomically so two agents do not silently perform the same task.
Tool/workspace contract
The control plane should consume .mnehmos/tool.json from distributable repositories.
A tool record should define:
- stable tool id/name
- repository
- package channels (
npm,pypi, MCP Registry, binary/app) - package names and executable entrypoints
- runtime/system requirements
- build/test/start/health commands
- external dependencies
- permissions/capabilities
- workspace input/output/state paths
- release/distribution metadata
A workspace is an operational instance of a tool/project, not merely a folder. It should record:
- tool id
- repository + branch/worktree/ref
- linked issue/task
- assigned agent(s)
- environment/config requirements
- bootstrap status
- build/test/health status
- state/artifact paths
- activity/events
Phase 1 may coordinate workspaces as metadata and repo/branch references. Actual remote/container workspace provisioning can be added behind the same API later.
Agent model
Each agent gets:
- stable agent id
- display name/type/model/provider
- scoped API credential
- declared capabilities
- allowed repositories/domains
- heartbeat/online state
- active task/workspace
- event/audit history
Example scopes:
tasks:readtasks:writetasks:claimtools:readworkspaces:readworkspaces:writereleases:writemarketing:writeartifacts:write
Never expose administrator session credentials to agents.
Distribution dashboard
Seed the dashboard with the current audit and track, per tool:
- GitHub repo
- license
- package channel
- package name/version
- monthly downloads
- MCP Registry status
- release readiness
- workspace-manifest readiness
- README/demo readiness
- open distribution issue
- next action
First-wave repos already have distribution/workspace issues and should be linked into this dashboard rather than copied into disconnected notes.
Marketing coordination
Add campaign records linked to tools/releases/tasks.
Track:
- launch/release being promoted
- message/hook
- demo asset
- target channels
- draft/post status
- published URLs
- impressions/clicks/conversions where available
- agent responsible
Agents should be able to create draft campaign tasks through the API, but external posting should require an explicit permission/scope and retain an audit event.
Audit/event model
Every agent/admin mutation should append an event:
- actor
- action
- resource type/id
- before/after or patch
- timestamp
- optional rationale/result/artifact URL
This becomes the shared coordination history and makes agent work inspectable.
Delivery phases
Phase 1: control-plane foundation
- Switch Astro deployment to SSR-capable host/runtime.
- Add database schema/migrations.
- Add administrator login.
- Add tool/task/workspace/agent/event models.
- Add
/api/v1auth and core task/tool/workspace endpoints. - Implement Kanban admin board.
- Seed current distribution audit and GitHub issue links.
Phase 2: repo manifests + release/distribution
- Define/version
.mnehmos/tool.jsonJSON Schema. - Add manifest ingestion/sync.
- Add registry/package/download fields and refresh jobs.
- Add release queue and readiness checks.
- Add tool-specific workspace bootstrap metadata/status.
Phase 3: marketing operations
- Campaign/artifact model.
- Marketing Kanban views/filters.
- Metrics ingestion.
- Agent-generated launch kits and campaign tasks.
Phase 4: active workspace orchestration
- Add pluggable workspace provisioner/worker.
- Spawn isolated repo workspaces/containers from manifests.
- Stream build/test/health status into dashboard.
- Allow agents to claim and execute eligible tasks through scoped API workflows.
Acceptance criteria for MVP
- Owner can log into
/admin. - Owner can create/edit/reorder Kanban tasks.
- Agent with scoped token can query, create, claim, update, and complete permitted tasks through
/api/v1. - Tasks can link a repo, GitHub issue, tool, workspace, and artifacts.
- Current distribution audit appears in
/admin/toolswith readiness states and issue links. - Workspace records can be created for a specific tool/repo/task using
.mnehmos/tool.jsonmetadata when available. - Every mutation produces an auditable activity event.
- Public site remains operational and does not expose admin/API secrets.
Activity
Mnehmos commentedon Sep 11, 2026
Architecture update: move the organizational control-plane implementation to
Mnehmos/The-Mnemosyne-Research-Institute#10. The Institute repo already owns organization identity, members, Google Workspace, email aliases, infrastructure, projects, and operational policy.Mnehmos/Mnehmosshould remain the public developer/product surface and consume approved public project/distribution metadata through the shared contract tracked in Institute issue #9. The distribution UI can remain public here, but staff identities, Kanban state, workspaces, email/tickets, approvals, and audit events should live under Institute Ops.