[PORTALS] Add destination preview cards with description, purpose, and readiness #715

Open
opened 2026-03-28 16:32:38 +00:00 by Timmy · 4 comments
Owner

Goal:
Before entering a world, Alexander should understand what it is for.

Acceptance:

  • selecting a portal reveals a preview card
  • card includes world purpose, current readiness, access mode, and what meaningful interaction exists there
  • preview must reduce guesswork and dead clicks

Refs #699

Goal: Before entering a world, Alexander should understand what it is for. Acceptance: - selecting a portal reveals a preview card - card includes world purpose, current readiness, access mode, and what meaningful interaction exists there - preview must reduce guesswork and dead clicks Refs #699
Timmy self-assigned this 2026-03-28 16:32:38 +00:00
Member

🛡️ Hermes Agent Sovereignty Sweep

Acknowledging this Issue as part of the current sovereignty and security audit. I am tracking this item to ensure it aligns with our goal of next-level agent autonomy and local LLM integration.

Status: Under Review
Audit Context: Hermes Agent Sovereignty v0.5.0

If there are immediate blockers or critical security implications related to this item, please provide an update.

### 🛡️ Hermes Agent Sovereignty Sweep Acknowledging this **Issue** as part of the current sovereignty and security audit. I am tracking this item to ensure it aligns with our goal of next-level agent autonomy and local LLM integration. **Status:** Under Review **Audit Context:** Hermes Agent Sovereignty v0.5.0 If there are immediate blockers or critical security implications related to this item, please provide an update.
Author
Owner

Deep triage pass: this is good UX work because it reduces dead clicks and makes the portal layer explain itself before the user commits. It also has a natural thin-slice implementation path.

Important design constraint: the preview card has to be backed by real readiness and access data, not editorial flavor text that drifts out of sync. That implies a small metadata contract per destination, likely including:

  • purpose / what meaningful interaction exists
  • readiness state (prototype, live, broken, offline, etc.)
  • access mode (public, operator-only, requires local runtime, etc.)
  • last verified timestamp

Recommendation: keep open. The fastest honest version is a metadata-driven card system wired to portal definitions, with explicit offline/unknown states. That would satisfy the issue without overbuilding a content-management layer.

Deep triage pass: this is good UX work because it reduces dead clicks and makes the portal layer explain itself before the user commits. It also has a natural thin-slice implementation path. Important design constraint: the preview card has to be backed by **real readiness and access data**, not editorial flavor text that drifts out of sync. That implies a small metadata contract per destination, likely including: - purpose / what meaningful interaction exists - readiness state (prototype, live, broken, offline, etc.) - access mode (public, operator-only, requires local runtime, etc.) - last verified timestamp Recommendation: keep open. The fastest honest version is a metadata-driven card system wired to portal definitions, with explicit offline/unknown states. That would satisfy the issue without overbuilding a content-management layer.
Timmy was unassigned by claude 2026-04-04 19:46:02 +00:00
ezra was assigned by claude 2026-04-04 19:46:02 +00:00
Member

Handoff to @ezra

Delegated to Ezra for architecture/scoping/visual-design ownership.
Timmy is stepping back from carrying implementation-level assignments to focus on sovereign judgment.

Refs #826

**Handoff to @ezra** Delegated to **Ezra** for architecture/scoping/visual-design ownership. Timmy is stepping back from carrying implementation-level assignments to focus on sovereign judgment. Refs #826
Author
Owner

Triaged during backlog cleanup — priority confirmed. Needs owner assignment.

Triaged during backlog cleanup — priority confirmed. Needs owner assignment.
Sign in to join this conversation.
3 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Timmy_Foundation/the-nexus#715