Date: 2026-04-09 Status: Implementation strategy / Track A follow-on Scope: Define the user-facing and data-shape rules for opt-in discovery packs that seed Graphshell with trusted or user-selected smolweb sources.

Related:

• NAVIGATOR.md
• 2026-04-09_source_subscription_manager_and_health.md
• ../../research/2026-04-09_smolweb_graph_enrichment_and_accessibility_note.md
• ../../research/2026-04-09_smolweb_discovery_and_aggregation_signal_model.md

---

Graphshell should not hardcode one canonical smolweb universe. It should allow users to opt into discovery packs that seed:

• candidate sources,
• wayfinding surfaces,
• community hubs,
• example feeds and capsules.

Discovery packs are a user-visible onboarding and exploration feature, not a hidden system default.

---

Each pack manifest should declare at least:

• pack id,
• display name,
• description,
• source or curator provenance,
• version,
• item list,
• recommended lane tags,
• optional removal policy,
• optional update channel.

Each pack item should declare:

• canonical address or URL,
• item kind,
• label,
• optional description,
• discovery lane,
• optional tags,
• optional grouping/section hint.

---

Discovery pack items may include:

• source candidates,
• subscription recommendations,
• wayfinding hubs,
• search engines,
• channel/community surfaces,
• exemplar documents or onboarding pages.

Important rule:

• installing a pack must not silently subscribe the user to everything in it unless the pack type explicitly says that is its behavior and the user opted into that mode.

Default interpretation:

• pack installation creates curated discovery candidates,
• the user decides which of those become actual subscriptions or saved sources.

---

The first install flow should be:

1. inspect pack metadata,
2. preview included items,
3. install as candidate sources,
4. optionally promote chosen items into subscriptions,
5. preserve pack provenance so later removal is reversible.

Pack install should be explicit and inspectable, not a hidden first-run seed.

---

Users should be able to:

• remove a pack while keeping explicitly subscribed sources,
• remove a pack and all still-pack-only candidates,
• inspect which sources came from the pack,
• refresh the pack definition when an update exists.

This keeps discovery packs from feeling like one-way imports.

---

Every candidate or source created by a discovery pack should retain:

• pack id,
• pack version,
• pack curator/source,
• install time,
• whether the user later promoted or edited the source manually.

That provenance is necessary for explainability and later cleanup.

---

Suitable early packs include:

• Bubble spaces,
• Cosmos-related sources,
• Wander consoles,
• curated Gemini feeds,
• trusted community hubs,
• learning packs for first-time smolweb exploration.

The goal is not to canonize one public web. The goal is to make opt-in exploration easier.

---

• define a manifest shape with pack metadata, item list, version, and curator provenance,
• validate item kinds and canonical addresses,
• keep pack provenance explicit and durable.

• allow a user to inspect pack metadata before installation,
• preview included items,
• install pack items as candidates by default rather than silent subscriptions.

• track which sources were created by which pack,
• allow removal of pack-only candidates,
• preserve explicitly promoted subscriptions on pack removal unless the user requests otherwise.

• support pack version refresh,
• show which new or changed items would be introduced,
• preserve install-time provenance for audit and rollback.

---

1. Inspect a discovery pack before installation and verify included items are previewable.
2. Install a pack and verify items land as candidates unless explicitly marked otherwise.
3. Promote one candidate to subscribed, remove the pack, and verify the explicit subscription remains.
4. Refresh a pack definition and verify version/provenance are visible.

• manifest-parse tests,
• provenance tests for pack install and removal,
• reducer or action tests for preview/install/remove/update flows.

---

This slice closes when:

• discovery packs have a stable manifest schema,
• install is previewable and explicit,
• pack-created candidates retain provenance,
• and pack removal/update flows are reversible and understandable.