@ritualai/cli 0.7.10 → 0.7.11

package/skills/cursor/ritual/references/build-flow.md

@@ -397,7 +397,7 @@ Steps:
      > **{candidate.name}** *(LLM confidence: {Math.round(candidate.llmConfidence * 100)}%)*
      > - *"{candidate.problemStatement first 120 chars, no ellipsis padding}..."*
      > - Why I think it overlaps: {candidate.llmRationale}
-     > - URL: `https://dev.ritualapp.cloud/e/{candidate.explorationId}`
+     > - URL: `https://app.ritualapp.cloud/e/{candidate.explorationId}`
      > {endfor}
      >
      > **Choose:**
@@ -983,7 +983,7 @@ Optimize for:
 
 References:
 - {RB/decision/exploration label} — {one-line meaning}
-  Source: {exploration title or id}{ optional ': https://dev.ritualapp.cloud/e/{exploration_id}' if available}
+  Source: {exploration title or id}{ optional ': https://app.ritualapp.cloud/e/{exploration_id}' if available}
 - {reference}
 
 Reply `use` to use this frame and review discovery questions.
@@ -1040,7 +1040,7 @@ Store `exploration_id`. Move the progress header from Scope to Discovery:
 Ritual build
 ✓ Context  ✓ Scope  ● Discovery  ○ Recommendations  ○ Build brief  ○ Implementation (Your agent)
 
-Exploration created. Track progress at https://dev.ritualapp.cloud/e/{exploration_id}
+Exploration created. Track progress at https://app.ritualapp.cloud/e/{exploration_id}
 
 Next: generate discovery questions to resolve the implementation trade-offs.
 ```
@@ -1504,10 +1504,67 @@ If you don't already know the user's role on this workspace, prefer the workspac
 
 ##### 9.1 — Landing screen: grouped category summary + compact scope
 
-The recommendations review is the most-read screen in the whole build flow. Two design rules:
+The recommendations review is the most-read screen in the whole build flow.
 
-1. **Group by `metadata.category.name`.** NEVER show a flat numbered 1..N list. The category is the organizing unit; recommendations are stable `R1..RN` IDs assigned in order of appearance ACROSS categories (top-to-bottom, NOT per-category — so a user can say `detail R7` unambiguously without naming the category).
-2. **Compact scope reference at top.** Show a single-line compressed version of the problem statement so the user can read recommendations against what they were optimized for. Support `show scope` to expand to full.
+```text
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+STEP 9.1 RENDERING CONTRACT — non-negotiable
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+Landing view is for SELECTION, not reading. Full prose belongs in 9.3.
+
+✓ DO:
+- Number categories `1.`, `2.`, `3.` … `K.` in page order
+- Assign recommendations stable `R1`, `R2`, … `RN` IDs GLOBALLY across
+  all categories (NOT restart per-category — so `detail R7` is
+  unambiguous without naming the category)
+- Show recommendation TITLES ONLY at the landing
+- Indent recs 3 spaces under their category
+- One blank line between categories
+- Include compact scope line above the list
+- End with the action block (`accept recommended` etc.)
+
+✗ DO NOT:
+- Do NOT render recs as a flat `1..N` list with no category structure
+- Do NOT use raw numeric rec IDs like `1.`, `2.`, `3.` — use `R1`, `R2`, `R3`
+- Do NOT show recommendation `content` / summary text at the landing
+- Do NOT show acceptance criteria, rationale, tactics, or references at
+  the landing — those are 9.3 detail-card content
+- Do NOT omit category numbering (the prefix is what separates this
+  from a wall-of-text grouped list)
+- Do NOT invent a "raw / deduped" framing line — the API does not return
+  pre-dedup counts. Use `{N} recommendations across {K} categories.`
+
+OBSERVED FAILURE — never render this:
+
+  Recommendations (13)
+
+  1. Backfill legacy data to fail-closed PRIVATE visibility
+     Add a constrained `visibility` field with DB default PRIVATE...
+
+  2. Codify actor-state rights around owner-only mutation
+     Define a single permission matrix across PRIVATE/SHARED/PUBLIC...
+
+  3. Centralize object permissions across storefront and dashboard
+     Reusable `can_view_wishlist` / `can_edit_wishlist` methods...
+
+Why wrong:
+  - Looks grouped only implicitly; categories not visible as headers
+  - Uses `1..N` numeric IDs (should be `R1..RN`)
+  - Dumps `content` summaries — defeats the purpose of a landing view
+  - `detail R7` no longer maps to a stable ID
+
+PREFLIGHT — before printing 9.1 output, self-check:
+  □ Did I group by `metadata.category.name`?
+  □ Did I prefix each category with `1.`, `2.`, … `K.`?
+  □ Did I assign global `R1..RN` IDs across categories?
+  □ Did I show titles only (no summaries / no rationale)?
+  □ Is there a compact scope line above the list?
+  □ Does my action block use `R{N}` references that match the IDs above?
+
+If any answer is no, FIX BEFORE PRINTING.
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+```
 
 Full rail at the landing (Recommendations stage opens):
 
@@ -1542,7 +1599,11 @@ Pulse: Reasoning Readiness ~88% · Context Debt 12% · +26% (implementation-read
 Recommended: reply `accept recommended` to approve these {N} and generate
 the build brief.
 
-Or reply `detail R7`, `change R3: <edit>`, `drop R8`, `add <topic>`, or `hold`.
+Or reply:
+- `detail R7` to inspect one recommendation
+- `drop R8` to remove one before accepting
+- `change R3: <edit>` to revise one
+- `hold` to stop here
 ```
 
 Notes:
@@ -1551,7 +1612,9 @@ Notes:
 - **One blank line between categories**; titles indent at 3 spaces (so the eye lands on the category name first, then the R-IDs scan down).
 - **Pulse uses full labels** per `references/cli-output-contract.md` § Pulse tier labels.
 - **`accept recommended`** is the visible CTA — NOT `accept all`. "Recommended" frames the action as "the curated set you see on screen"; "all" sounds like a bulk operation over deduped/hidden/raw recs.
-- **`add <topic>`** lets the user request an additional recommendation on the fly (e.g. `add telemetry` → agent calls `regenerate_recommendation` with a new rec hint, or asks the user to clarify what's missing). If the backing API doesn't yet support targeted single-rec addition, prompt the user with: "I can add a rec for `{topic}` by regenerating the full set with that pinned — that takes ~30s. Or hold the current set and add manually via the web UI."
+- **Surface 4 actions at first render — not more.** The four above (`detail R{N}`, `drop R{N}`, `change R{N}: <edit>`, `hold`) cover the decisive cases. Less-frequent actions stay discoverable but off-screen at the landing:
+  - **`add <topic>`** lets the user request an additional recommendation on the fly (e.g. `add telemetry` → agent calls `regenerate_recommendation` with a new rec hint, or asks the user to clarify what's missing). Surface it in `help` or on the 9.3 detail card, NOT in the landing action line — too many actions at once weakens the selection screen. If the backing API doesn't yet support targeted single-rec addition, prompt the user with: "I can add a rec for `{topic}` by regenerating the full set with that pinned — that takes ~30s. Or hold the current set and add manually via the web UI."
+  - **`show scope`** to expand the full problem statement (covered in 9.2).
 
 ##### 9.2 — `show scope` handling
 
@@ -1646,7 +1709,7 @@ Ritual build
 
 Accepted {N} recommendations.
 
-View: https://dev.ritualapp.cloud/e/{exploration_id}
+View: https://app.ritualapp.cloud/e/{exploration_id}
 
 Next: generating the build brief…
 ```
@@ -1783,7 +1846,7 @@ When the brief content is in hand (from generate OR polling), **don't dump 300 l
    ```markdown
    <!--
    Generated by Ritual
-   Exploration: https://dev.ritualapp.cloud/e/{exploration_id}
+   Exploration: https://app.ritualapp.cloud/e/{exploration_id}
    Build brief id: {brief_id}
    Do not remove this header; it preserves implementation lineage.
    -->
@@ -1927,7 +1990,7 @@ feat(<area>): <one-line headline>
 <short body — what changed, why, key trade-off>
 
 Ritual-Exploration: <exploration_id>
-Ritual-Exploration-Url: https://dev.ritualapp.cloud/e/<exploration_id>
+Ritual-Exploration-Url: https://app.ritualapp.cloud/e/<exploration_id>
 Ritual-RBs-Satisfied: RB-1, RB-2, RB-7
 ```
 
@@ -1980,7 +2043,7 @@ If the user says "y" / "push" / "open PR":
 
 ## Exploration
 
-- Exploration: [<exploration name>](https://dev.ritualapp.cloud/e/<exploration_id>)
+- Exploration: [<exploration name>](https://app.ritualapp.cloud/e/<exploration_id>)
 - Build brief: see `BUILD-BRIEF.md` (committed in this PR for reviewer reference)
 - Deferrals intentionally punted: <count, with one-line each>
 

package/skills/gemini/ritual/.ritual-bundle.json

@@ -0,0 +1,4 @@
+{
+  "cliVersion": "0.7.11",
+  "builtAt": "2026-05-14T12:14:29.050Z"
+}

package/skills/gemini/ritual/references/build-flow.md

@@ -397,7 +397,7 @@ Steps:
      > **{candidate.name}** *(LLM confidence: {Math.round(candidate.llmConfidence * 100)}%)*
      > - *"{candidate.problemStatement first 120 chars, no ellipsis padding}..."*
      > - Why I think it overlaps: {candidate.llmRationale}
-     > - URL: `https://dev.ritualapp.cloud/e/{candidate.explorationId}`
+     > - URL: `https://app.ritualapp.cloud/e/{candidate.explorationId}`
      > {endfor}
      >
      > **Choose:**
@@ -983,7 +983,7 @@ Optimize for:
 
 References:
 - {RB/decision/exploration label} — {one-line meaning}
-  Source: {exploration title or id}{ optional ': https://dev.ritualapp.cloud/e/{exploration_id}' if available}
+  Source: {exploration title or id}{ optional ': https://app.ritualapp.cloud/e/{exploration_id}' if available}
 - {reference}
 
 Reply `use` to use this frame and review discovery questions.
@@ -1040,7 +1040,7 @@ Store `exploration_id`. Move the progress header from Scope to Discovery:
 Ritual build
 ✓ Context  ✓ Scope  ● Discovery  ○ Recommendations  ○ Build brief  ○ Implementation (Your agent)
 
-Exploration created. Track progress at https://dev.ritualapp.cloud/e/{exploration_id}
+Exploration created. Track progress at https://app.ritualapp.cloud/e/{exploration_id}
 
 Next: generate discovery questions to resolve the implementation trade-offs.
 ```
@@ -1504,10 +1504,67 @@ If you don't already know the user's role on this workspace, prefer the workspac
 
 ##### 9.1 — Landing screen: grouped category summary + compact scope
 
-The recommendations review is the most-read screen in the whole build flow. Two design rules:
+The recommendations review is the most-read screen in the whole build flow.
 
-1. **Group by `metadata.category.name`.** NEVER show a flat numbered 1..N list. The category is the organizing unit; recommendations are stable `R1..RN` IDs assigned in order of appearance ACROSS categories (top-to-bottom, NOT per-category — so a user can say `detail R7` unambiguously without naming the category).
-2. **Compact scope reference at top.** Show a single-line compressed version of the problem statement so the user can read recommendations against what they were optimized for. Support `show scope` to expand to full.
+```text
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+STEP 9.1 RENDERING CONTRACT — non-negotiable
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+Landing view is for SELECTION, not reading. Full prose belongs in 9.3.
+
+✓ DO:
+- Number categories `1.`, `2.`, `3.` … `K.` in page order
+- Assign recommendations stable `R1`, `R2`, … `RN` IDs GLOBALLY across
+  all categories (NOT restart per-category — so `detail R7` is
+  unambiguous without naming the category)
+- Show recommendation TITLES ONLY at the landing
+- Indent recs 3 spaces under their category
+- One blank line between categories
+- Include compact scope line above the list
+- End with the action block (`accept recommended` etc.)
+
+✗ DO NOT:
+- Do NOT render recs as a flat `1..N` list with no category structure
+- Do NOT use raw numeric rec IDs like `1.`, `2.`, `3.` — use `R1`, `R2`, `R3`
+- Do NOT show recommendation `content` / summary text at the landing
+- Do NOT show acceptance criteria, rationale, tactics, or references at
+  the landing — those are 9.3 detail-card content
+- Do NOT omit category numbering (the prefix is what separates this
+  from a wall-of-text grouped list)
+- Do NOT invent a "raw / deduped" framing line — the API does not return
+  pre-dedup counts. Use `{N} recommendations across {K} categories.`
+
+OBSERVED FAILURE — never render this:
+
+  Recommendations (13)
+
+  1. Backfill legacy data to fail-closed PRIVATE visibility
+     Add a constrained `visibility` field with DB default PRIVATE...
+
+  2. Codify actor-state rights around owner-only mutation
+     Define a single permission matrix across PRIVATE/SHARED/PUBLIC...
+
+  3. Centralize object permissions across storefront and dashboard
+     Reusable `can_view_wishlist` / `can_edit_wishlist` methods...
+
+Why wrong:
+  - Looks grouped only implicitly; categories not visible as headers
+  - Uses `1..N` numeric IDs (should be `R1..RN`)
+  - Dumps `content` summaries — defeats the purpose of a landing view
+  - `detail R7` no longer maps to a stable ID
+
+PREFLIGHT — before printing 9.1 output, self-check:
+  □ Did I group by `metadata.category.name`?
+  □ Did I prefix each category with `1.`, `2.`, … `K.`?
+  □ Did I assign global `R1..RN` IDs across categories?
+  □ Did I show titles only (no summaries / no rationale)?
+  □ Is there a compact scope line above the list?
+  □ Does my action block use `R{N}` references that match the IDs above?
+
+If any answer is no, FIX BEFORE PRINTING.
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+```
 
 Full rail at the landing (Recommendations stage opens):
 
@@ -1542,7 +1599,11 @@ Pulse: Reasoning Readiness ~88% · Context Debt 12% · +26% (implementation-read
 Recommended: reply `accept recommended` to approve these {N} and generate
 the build brief.
 
-Or reply `detail R7`, `change R3: <edit>`, `drop R8`, `add <topic>`, or `hold`.
+Or reply:
+- `detail R7` to inspect one recommendation
+- `drop R8` to remove one before accepting
+- `change R3: <edit>` to revise one
+- `hold` to stop here
 ```
 
 Notes:
@@ -1551,7 +1612,9 @@ Notes:
 - **One blank line between categories**; titles indent at 3 spaces (so the eye lands on the category name first, then the R-IDs scan down).
 - **Pulse uses full labels** per `references/cli-output-contract.md` § Pulse tier labels.
 - **`accept recommended`** is the visible CTA — NOT `accept all`. "Recommended" frames the action as "the curated set you see on screen"; "all" sounds like a bulk operation over deduped/hidden/raw recs.
-- **`add <topic>`** lets the user request an additional recommendation on the fly (e.g. `add telemetry` → agent calls `regenerate_recommendation` with a new rec hint, or asks the user to clarify what's missing). If the backing API doesn't yet support targeted single-rec addition, prompt the user with: "I can add a rec for `{topic}` by regenerating the full set with that pinned — that takes ~30s. Or hold the current set and add manually via the web UI."
+- **Surface 4 actions at first render — not more.** The four above (`detail R{N}`, `drop R{N}`, `change R{N}: <edit>`, `hold`) cover the decisive cases. Less-frequent actions stay discoverable but off-screen at the landing:
+  - **`add <topic>`** lets the user request an additional recommendation on the fly (e.g. `add telemetry` → agent calls `regenerate_recommendation` with a new rec hint, or asks the user to clarify what's missing). Surface it in `help` or on the 9.3 detail card, NOT in the landing action line — too many actions at once weakens the selection screen. If the backing API doesn't yet support targeted single-rec addition, prompt the user with: "I can add a rec for `{topic}` by regenerating the full set with that pinned — that takes ~30s. Or hold the current set and add manually via the web UI."
+  - **`show scope`** to expand the full problem statement (covered in 9.2).
 
 ##### 9.2 — `show scope` handling
 
@@ -1646,7 +1709,7 @@ Ritual build
 
 Accepted {N} recommendations.
 
-View: https://dev.ritualapp.cloud/e/{exploration_id}
+View: https://app.ritualapp.cloud/e/{exploration_id}
 
 Next: generating the build brief…
 ```
@@ -1783,7 +1846,7 @@ When the brief content is in hand (from generate OR polling), **don't dump 300 l
    ```markdown
    <!--
    Generated by Ritual
-   Exploration: https://dev.ritualapp.cloud/e/{exploration_id}
+   Exploration: https://app.ritualapp.cloud/e/{exploration_id}
    Build brief id: {brief_id}
    Do not remove this header; it preserves implementation lineage.
    -->
@@ -1927,7 +1990,7 @@ feat(<area>): <one-line headline>
 <short body — what changed, why, key trade-off>
 
 Ritual-Exploration: <exploration_id>
-Ritual-Exploration-Url: https://dev.ritualapp.cloud/e/<exploration_id>
+Ritual-Exploration-Url: https://app.ritualapp.cloud/e/<exploration_id>
 Ritual-RBs-Satisfied: RB-1, RB-2, RB-7
 ```
 
@@ -1980,7 +2043,7 @@ If the user says "y" / "push" / "open PR":
 
 ## Exploration
 
-- Exploration: [<exploration name>](https://dev.ritualapp.cloud/e/<exploration_id>)
+- Exploration: [<exploration name>](https://app.ritualapp.cloud/e/<exploration_id>)
 - Build brief: see `BUILD-BRIEF.md` (committed in this PR for reviewer reference)
 - Deferrals intentionally punted: <count, with one-line each>
 

package/skills/kiro/ritual/.ritual-bundle.json

@@ -0,0 +1,4 @@
+{
+  "cliVersion": "0.7.11",
+  "builtAt": "2026-05-14T12:14:29.050Z"
+}

package/skills/kiro/ritual/references/build-flow.md

@@ -397,7 +397,7 @@ Steps:
      > **{candidate.name}** *(LLM confidence: {Math.round(candidate.llmConfidence * 100)}%)*
      > - *"{candidate.problemStatement first 120 chars, no ellipsis padding}..."*
      > - Why I think it overlaps: {candidate.llmRationale}
-     > - URL: `https://dev.ritualapp.cloud/e/{candidate.explorationId}`
+     > - URL: `https://app.ritualapp.cloud/e/{candidate.explorationId}`
      > {endfor}
      >
      > **Choose:**
@@ -983,7 +983,7 @@ Optimize for:
 
 References:
 - {RB/decision/exploration label} — {one-line meaning}
-  Source: {exploration title or id}{ optional ': https://dev.ritualapp.cloud/e/{exploration_id}' if available}
+  Source: {exploration title or id}{ optional ': https://app.ritualapp.cloud/e/{exploration_id}' if available}
 - {reference}
 
 Reply `use` to use this frame and review discovery questions.
@@ -1040,7 +1040,7 @@ Store `exploration_id`. Move the progress header from Scope to Discovery:
 Ritual build
 ✓ Context  ✓ Scope  ● Discovery  ○ Recommendations  ○ Build brief  ○ Implementation (Your agent)
 
-Exploration created. Track progress at https://dev.ritualapp.cloud/e/{exploration_id}
+Exploration created. Track progress at https://app.ritualapp.cloud/e/{exploration_id}
 
 Next: generate discovery questions to resolve the implementation trade-offs.
 ```
@@ -1504,10 +1504,67 @@ If you don't already know the user's role on this workspace, prefer the workspac
 
 ##### 9.1 — Landing screen: grouped category summary + compact scope
 
-The recommendations review is the most-read screen in the whole build flow. Two design rules:
+The recommendations review is the most-read screen in the whole build flow.
 
-1. **Group by `metadata.category.name`.** NEVER show a flat numbered 1..N list. The category is the organizing unit; recommendations are stable `R1..RN` IDs assigned in order of appearance ACROSS categories (top-to-bottom, NOT per-category — so a user can say `detail R7` unambiguously without naming the category).
-2. **Compact scope reference at top.** Show a single-line compressed version of the problem statement so the user can read recommendations against what they were optimized for. Support `show scope` to expand to full.
+```text
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+STEP 9.1 RENDERING CONTRACT — non-negotiable
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+Landing view is for SELECTION, not reading. Full prose belongs in 9.3.
+
+✓ DO:
+- Number categories `1.`, `2.`, `3.` … `K.` in page order
+- Assign recommendations stable `R1`, `R2`, … `RN` IDs GLOBALLY across
+  all categories (NOT restart per-category — so `detail R7` is
+  unambiguous without naming the category)
+- Show recommendation TITLES ONLY at the landing
+- Indent recs 3 spaces under their category
+- One blank line between categories
+- Include compact scope line above the list
+- End with the action block (`accept recommended` etc.)
+
+✗ DO NOT:
+- Do NOT render recs as a flat `1..N` list with no category structure
+- Do NOT use raw numeric rec IDs like `1.`, `2.`, `3.` — use `R1`, `R2`, `R3`
+- Do NOT show recommendation `content` / summary text at the landing
+- Do NOT show acceptance criteria, rationale, tactics, or references at
+  the landing — those are 9.3 detail-card content
+- Do NOT omit category numbering (the prefix is what separates this
+  from a wall-of-text grouped list)
+- Do NOT invent a "raw / deduped" framing line — the API does not return
+  pre-dedup counts. Use `{N} recommendations across {K} categories.`
+
+OBSERVED FAILURE — never render this:
+
+  Recommendations (13)
+
+  1. Backfill legacy data to fail-closed PRIVATE visibility
+     Add a constrained `visibility` field with DB default PRIVATE...
+
+  2. Codify actor-state rights around owner-only mutation
+     Define a single permission matrix across PRIVATE/SHARED/PUBLIC...
+
+  3. Centralize object permissions across storefront and dashboard
+     Reusable `can_view_wishlist` / `can_edit_wishlist` methods...
+
+Why wrong:
+  - Looks grouped only implicitly; categories not visible as headers
+  - Uses `1..N` numeric IDs (should be `R1..RN`)
+  - Dumps `content` summaries — defeats the purpose of a landing view
+  - `detail R7` no longer maps to a stable ID
+
+PREFLIGHT — before printing 9.1 output, self-check:
+  □ Did I group by `metadata.category.name`?
+  □ Did I prefix each category with `1.`, `2.`, … `K.`?
+  □ Did I assign global `R1..RN` IDs across categories?
+  □ Did I show titles only (no summaries / no rationale)?
+  □ Is there a compact scope line above the list?
+  □ Does my action block use `R{N}` references that match the IDs above?
+
+If any answer is no, FIX BEFORE PRINTING.
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+```
 
 Full rail at the landing (Recommendations stage opens):
 
@@ -1542,7 +1599,11 @@ Pulse: Reasoning Readiness ~88% · Context Debt 12% · +26% (implementation-read
 Recommended: reply `accept recommended` to approve these {N} and generate
 the build brief.
 
-Or reply `detail R7`, `change R3: <edit>`, `drop R8`, `add <topic>`, or `hold`.
+Or reply:
+- `detail R7` to inspect one recommendation
+- `drop R8` to remove one before accepting
+- `change R3: <edit>` to revise one
+- `hold` to stop here
 ```
 
 Notes:
@@ -1551,7 +1612,9 @@ Notes:
 - **One blank line between categories**; titles indent at 3 spaces (so the eye lands on the category name first, then the R-IDs scan down).
 - **Pulse uses full labels** per `references/cli-output-contract.md` § Pulse tier labels.
 - **`accept recommended`** is the visible CTA — NOT `accept all`. "Recommended" frames the action as "the curated set you see on screen"; "all" sounds like a bulk operation over deduped/hidden/raw recs.
-- **`add <topic>`** lets the user request an additional recommendation on the fly (e.g. `add telemetry` → agent calls `regenerate_recommendation` with a new rec hint, or asks the user to clarify what's missing). If the backing API doesn't yet support targeted single-rec addition, prompt the user with: "I can add a rec for `{topic}` by regenerating the full set with that pinned — that takes ~30s. Or hold the current set and add manually via the web UI."
+- **Surface 4 actions at first render — not more.** The four above (`detail R{N}`, `drop R{N}`, `change R{N}: <edit>`, `hold`) cover the decisive cases. Less-frequent actions stay discoverable but off-screen at the landing:
+  - **`add <topic>`** lets the user request an additional recommendation on the fly (e.g. `add telemetry` → agent calls `regenerate_recommendation` with a new rec hint, or asks the user to clarify what's missing). Surface it in `help` or on the 9.3 detail card, NOT in the landing action line — too many actions at once weakens the selection screen. If the backing API doesn't yet support targeted single-rec addition, prompt the user with: "I can add a rec for `{topic}` by regenerating the full set with that pinned — that takes ~30s. Or hold the current set and add manually via the web UI."
+  - **`show scope`** to expand the full problem statement (covered in 9.2).
 
 ##### 9.2 — `show scope` handling
 
@@ -1646,7 +1709,7 @@ Ritual build
 
 Accepted {N} recommendations.
 
-View: https://dev.ritualapp.cloud/e/{exploration_id}
+View: https://app.ritualapp.cloud/e/{exploration_id}
 
 Next: generating the build brief…
 ```
@@ -1783,7 +1846,7 @@ When the brief content is in hand (from generate OR polling), **don't dump 300 l
    ```markdown
    <!--
    Generated by Ritual
-   Exploration: https://dev.ritualapp.cloud/e/{exploration_id}
+   Exploration: https://app.ritualapp.cloud/e/{exploration_id}
    Build brief id: {brief_id}
    Do not remove this header; it preserves implementation lineage.
    -->
@@ -1927,7 +1990,7 @@ feat(<area>): <one-line headline>
 <short body — what changed, why, key trade-off>
 
 Ritual-Exploration: <exploration_id>
-Ritual-Exploration-Url: https://dev.ritualapp.cloud/e/<exploration_id>
+Ritual-Exploration-Url: https://app.ritualapp.cloud/e/<exploration_id>
 Ritual-RBs-Satisfied: RB-1, RB-2, RB-7
 ```
 
@@ -1980,7 +2043,7 @@ If the user says "y" / "push" / "open PR":
 
 ## Exploration
 
-- Exploration: [<exploration name>](https://dev.ritualapp.cloud/e/<exploration_id>)
+- Exploration: [<exploration name>](https://app.ritualapp.cloud/e/<exploration_id>)
 - Build brief: see `BUILD-BRIEF.md` (committed in this PR for reviewer reference)
 - Deferrals intentionally punted: <count, with one-line each>
 

package/skills/vscode/ritual/.ritual-bundle.json

@@ -0,0 +1,4 @@
+{
+  "cliVersion": "0.7.11",
+  "builtAt": "2026-05-14T12:14:29.050Z"
+}

package/skills/vscode/ritual/references/build-flow.md

@@ -397,7 +397,7 @@ Steps:
      > **{candidate.name}** *(LLM confidence: {Math.round(candidate.llmConfidence * 100)}%)*
      > - *"{candidate.problemStatement first 120 chars, no ellipsis padding}..."*
      > - Why I think it overlaps: {candidate.llmRationale}
-     > - URL: `https://dev.ritualapp.cloud/e/{candidate.explorationId}`
+     > - URL: `https://app.ritualapp.cloud/e/{candidate.explorationId}`
      > {endfor}
      >
      > **Choose:**
@@ -983,7 +983,7 @@ Optimize for:
 
 References:
 - {RB/decision/exploration label} — {one-line meaning}
-  Source: {exploration title or id}{ optional ': https://dev.ritualapp.cloud/e/{exploration_id}' if available}
+  Source: {exploration title or id}{ optional ': https://app.ritualapp.cloud/e/{exploration_id}' if available}
 - {reference}
 
 Reply `use` to use this frame and review discovery questions.
@@ -1040,7 +1040,7 @@ Store `exploration_id`. Move the progress header from Scope to Discovery:
 Ritual build
 ✓ Context  ✓ Scope  ● Discovery  ○ Recommendations  ○ Build brief  ○ Implementation (Your agent)
 
-Exploration created. Track progress at https://dev.ritualapp.cloud/e/{exploration_id}
+Exploration created. Track progress at https://app.ritualapp.cloud/e/{exploration_id}
 
 Next: generate discovery questions to resolve the implementation trade-offs.
 ```
@@ -1504,10 +1504,67 @@ If you don't already know the user's role on this workspace, prefer the workspac
 
 ##### 9.1 — Landing screen: grouped category summary + compact scope
 
-The recommendations review is the most-read screen in the whole build flow. Two design rules:
+The recommendations review is the most-read screen in the whole build flow.
 
-1. **Group by `metadata.category.name`.** NEVER show a flat numbered 1..N list. The category is the organizing unit; recommendations are stable `R1..RN` IDs assigned in order of appearance ACROSS categories (top-to-bottom, NOT per-category — so a user can say `detail R7` unambiguously without naming the category).
-2. **Compact scope reference at top.** Show a single-line compressed version of the problem statement so the user can read recommendations against what they were optimized for. Support `show scope` to expand to full.
+```text
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+STEP 9.1 RENDERING CONTRACT — non-negotiable
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+
+Landing view is for SELECTION, not reading. Full prose belongs in 9.3.
+
+✓ DO:
+- Number categories `1.`, `2.`, `3.` … `K.` in page order
+- Assign recommendations stable `R1`, `R2`, … `RN` IDs GLOBALLY across
+  all categories (NOT restart per-category — so `detail R7` is
+  unambiguous without naming the category)
+- Show recommendation TITLES ONLY at the landing
+- Indent recs 3 spaces under their category
+- One blank line between categories
+- Include compact scope line above the list
+- End with the action block (`accept recommended` etc.)
+
+✗ DO NOT:
+- Do NOT render recs as a flat `1..N` list with no category structure
+- Do NOT use raw numeric rec IDs like `1.`, `2.`, `3.` — use `R1`, `R2`, `R3`
+- Do NOT show recommendation `content` / summary text at the landing
+- Do NOT show acceptance criteria, rationale, tactics, or references at
+  the landing — those are 9.3 detail-card content
+- Do NOT omit category numbering (the prefix is what separates this
+  from a wall-of-text grouped list)
+- Do NOT invent a "raw / deduped" framing line — the API does not return
+  pre-dedup counts. Use `{N} recommendations across {K} categories.`
+
+OBSERVED FAILURE — never render this:
+
+  Recommendations (13)
+
+  1. Backfill legacy data to fail-closed PRIVATE visibility
+     Add a constrained `visibility` field with DB default PRIVATE...
+
+  2. Codify actor-state rights around owner-only mutation
+     Define a single permission matrix across PRIVATE/SHARED/PUBLIC...
+
+  3. Centralize object permissions across storefront and dashboard
+     Reusable `can_view_wishlist` / `can_edit_wishlist` methods...
+
+Why wrong:
+  - Looks grouped only implicitly; categories not visible as headers
+  - Uses `1..N` numeric IDs (should be `R1..RN`)
+  - Dumps `content` summaries — defeats the purpose of a landing view
+  - `detail R7` no longer maps to a stable ID
+
+PREFLIGHT — before printing 9.1 output, self-check:
+  □ Did I group by `metadata.category.name`?
+  □ Did I prefix each category with `1.`, `2.`, … `K.`?
+  □ Did I assign global `R1..RN` IDs across categories?
+  □ Did I show titles only (no summaries / no rationale)?
+  □ Is there a compact scope line above the list?
+  □ Does my action block use `R{N}` references that match the IDs above?
+
+If any answer is no, FIX BEFORE PRINTING.
+━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
+```
 
 Full rail at the landing (Recommendations stage opens):
 
@@ -1542,7 +1599,11 @@ Pulse: Reasoning Readiness ~88% · Context Debt 12% · +26% (implementation-read
 Recommended: reply `accept recommended` to approve these {N} and generate
 the build brief.
 
-Or reply `detail R7`, `change R3: <edit>`, `drop R8`, `add <topic>`, or `hold`.
+Or reply:
+- `detail R7` to inspect one recommendation
+- `drop R8` to remove one before accepting
+- `change R3: <edit>` to revise one
+- `hold` to stop here
 ```
 
 Notes:
@@ -1551,7 +1612,9 @@ Notes:
 - **One blank line between categories**; titles indent at 3 spaces (so the eye lands on the category name first, then the R-IDs scan down).
 - **Pulse uses full labels** per `references/cli-output-contract.md` § Pulse tier labels.
 - **`accept recommended`** is the visible CTA — NOT `accept all`. "Recommended" frames the action as "the curated set you see on screen"; "all" sounds like a bulk operation over deduped/hidden/raw recs.
-- **`add <topic>`** lets the user request an additional recommendation on the fly (e.g. `add telemetry` → agent calls `regenerate_recommendation` with a new rec hint, or asks the user to clarify what's missing). If the backing API doesn't yet support targeted single-rec addition, prompt the user with: "I can add a rec for `{topic}` by regenerating the full set with that pinned — that takes ~30s. Or hold the current set and add manually via the web UI."
+- **Surface 4 actions at first render — not more.** The four above (`detail R{N}`, `drop R{N}`, `change R{N}: <edit>`, `hold`) cover the decisive cases. Less-frequent actions stay discoverable but off-screen at the landing:
+  - **`add <topic>`** lets the user request an additional recommendation on the fly (e.g. `add telemetry` → agent calls `regenerate_recommendation` with a new rec hint, or asks the user to clarify what's missing). Surface it in `help` or on the 9.3 detail card, NOT in the landing action line — too many actions at once weakens the selection screen. If the backing API doesn't yet support targeted single-rec addition, prompt the user with: "I can add a rec for `{topic}` by regenerating the full set with that pinned — that takes ~30s. Or hold the current set and add manually via the web UI."
+  - **`show scope`** to expand the full problem statement (covered in 9.2).
 
 ##### 9.2 — `show scope` handling
 
@@ -1646,7 +1709,7 @@ Ritual build
 
 Accepted {N} recommendations.
 
-View: https://dev.ritualapp.cloud/e/{exploration_id}
+View: https://app.ritualapp.cloud/e/{exploration_id}
 
 Next: generating the build brief…
 ```
@@ -1783,7 +1846,7 @@ When the brief content is in hand (from generate OR polling), **don't dump 300 l
    ```markdown
    <!--
    Generated by Ritual
-   Exploration: https://dev.ritualapp.cloud/e/{exploration_id}
+   Exploration: https://app.ritualapp.cloud/e/{exploration_id}
    Build brief id: {brief_id}
    Do not remove this header; it preserves implementation lineage.
    -->
@@ -1927,7 +1990,7 @@ feat(<area>): <one-line headline>
 <short body — what changed, why, key trade-off>
 
 Ritual-Exploration: <exploration_id>
-Ritual-Exploration-Url: https://dev.ritualapp.cloud/e/<exploration_id>
+Ritual-Exploration-Url: https://app.ritualapp.cloud/e/<exploration_id>
 Ritual-RBs-Satisfied: RB-1, RB-2, RB-7
 ```
 
@@ -1980,7 +2043,7 @@ If the user says "y" / "push" / "open PR":
 
 ## Exploration
 
-- Exploration: [<exploration name>](https://dev.ritualapp.cloud/e/<exploration_id>)
+- Exploration: [<exploration name>](https://app.ritualapp.cloud/e/<exploration_id>)
 - Build brief: see `BUILD-BRIEF.md` (committed in this PR for reviewer reference)
 - Deferrals intentionally punted: <count, with one-line each>