Feature description
Add a small, read-only Memory viewer to the web console so users can inspect an individual Memory entry without using the CLI or raw HTTP API.
This is a focused first step toward the broader web-console management UI in #1341 and should also provide a reusable web workflow for the desktop control center tracked in #1428.
Problem and proposed solution
The current Dashboard shows only aggregate Memory counts. The Server API already exposes POST /v1/memory/entries/list and POST /v1/memory/entries/get, but there is no web page that lets a user view the actual content of a Memory entry.
Add a read-only Memory page or panel that:
- uses the existing Dashboard authentication and Scope selection;
- lists active Memory entries for the selected Scope;
- lets the user select an entry;
- displays its text, kind, state, version, and citation;
- handles loading, empty, authentication, and error states clearly.
The implementation should use the existing server-rendered Jinja + vanilla ES module stack and the public HTTP API contract. It must not add editing, retiring, search, pagination, or desktop-specific behavior in this first slice.
Acceptance criteria
Out of scope
- Memory search
- Revise or retire actions
- Revision history and change audit timeline
- Artifact or Candidate management
- New API endpoints or database changes
- Native desktop implementation
Related issues
Contribution
Feature description
Add a small, read-only Memory viewer to the web console so users can inspect an individual Memory entry without using the CLI or raw HTTP API.
This is a focused first step toward the broader web-console management UI in #1341 and should also provide a reusable web workflow for the desktop control center tracked in #1428.
Problem and proposed solution
The current Dashboard shows only aggregate Memory counts. The Server API already exposes
POST /v1/memory/entries/listandPOST /v1/memory/entries/get, but there is no web page that lets a user view the actual content of a Memory entry.Add a read-only Memory page or panel that:
The implementation should use the existing server-rendered Jinja + vanilla ES module stack and the public HTTP API contract. It must not add editing, retiring, search, pagination, or desktop-specific behavior in this first slice.
Acceptance criteria
Out of scope
Related issues
Contribution