feat(ui): add maintenance page for task management

* Implement maintenance page with task and log display
* Add backfill and metadata retry functionality
* Integrate grid component for project display in thoughts page
* Update types for maintenance tasks and logs
* Enhance sidebar and shell for new maintenance navigation

README.md

@@ -31,6 +31,9 @@ The AMCS directory is used to store configuration and code for the Advanced Modu
 | `get_project_context` | Recent + semantic context for a project; uses explicit `project` or the active session project |
 | `set_active_project` | Set session project scope; requires a stateful MCP session |
 | `get_active_project` | Get current session project |
+| `add_learning` | Create a curated learning record distinct from raw thoughts |
+| `get_learning` | Retrieve a structured learning by ID |
+| `list_learnings` | List structured learnings by project/category/area/status/priority/tag/query |
 | `summarize_thoughts` | LLM prose summary over a filtered set |
 | `recall_context` | Semantic + recency context block for injection |
 | `link_thoughts` | Create a typed relationship between thoughts |
@@ -66,6 +69,17 @@ The AMCS directory is used to store configuration and code for the Advanced Modu
 | `describe_tools` | List all available MCP tools with names, descriptions, categories, and model-authored usage notes; call this at the start of a session to orient yourself |
 | `annotate_tool` | Persist your own usage notes for a specific tool; notes are returned by `describe_tools` in future sessions |
 
+## Learnings
+
+Learnings are curated, structured memory records for durable insights you want to keep distinct from raw thoughts. Use them for normalized lessons, decisions, and evidence-backed findings that should be easy to retrieve and review over time.
+
+Compared with `capture_thought`, learnings are more explicit and reviewable: they include a required `summary`, optional `details`, and structured fields like `category`, `area`, `status`, `priority`, `confidence`, and `tags`, plus optional links to a `project`, `related_thought_id`, or `related_skill_id`.
+
+Use:
+- `add_learning` to create a curated learning.
+- `get_learning` to fetch one by ID.
+- `list_learnings` to filter curated learnings across project and status dimensions.
+
 ## Self-Documenting Tools
 
 AMCS includes a built-in tool directory that models can read and annotate.
@@ -598,6 +612,26 @@ Run the SQL migrations against a local database with:
 
 The web UI now lives in the top-level `ui/` module and is embedded into the Go binary at build time with `go:embed`.
 
+### Admin UI deployment model
+
+AMCS uses a **lightweight embedded SPA panel** model:
+
+- the Svelte admin app is compiled to static assets
+- assets are embedded in the server binary and served from `/`
+- backend APIs (`/api/status`, `/api/rs/*`, admin action routes, OAuth endpoints) stay on the same origin
+- auth is enforced server-side for all sensitive API routes
+
+This keeps deployment simple (single binary/container) while preserving SPA ergonomics for operator workflows.
+
+### UI stack baseline
+
+The admin frontend baseline is:
+
+- Svelte 5 for the app shell and pages
+- ResolveSpec-backed APIs for data access
+- `@warkypublic/svelix` for admin UX components (including `GridlerFull` and form controllers)
+- `@warkypublic/artemis-kit` as the default JavaScript tooling dependency baseline in `ui/package.json`
+
 **Use `pnpm` for all UI work in this repo.**
 
 - `make build` — runs the real UI build first, then compiles the Go server