[feature-opportunities] Next feature opportunities

Feature health overview

The product is a static GitHub Pages curriculum: docs/build.js reads modules/<id>/challenges/<slug>/meta.yml and renders a catalog (docs/catalog.html), module pages (docs/module.html), a set builder for sharing custom activity lists (docs/builder.html, docs/assets/js/builder.js, docs/set.js), and individual activity guides (docs/challenge.html, docs/assets/js/challenge.js). Outcome journeys are curated in outcomes.json. There are 87 activities across 4 modules (ghec 53, ghas 7, ghaw 20, sre-agent 5).

Strengths: clean content/build separation (docs/build.js is the only bridge from meta.yml to rendered data), a shareable custom-set builder, outcome-based filtering, and a deterministic content audit (scripts/audit-content.js).

Gaps: the site has no persisted progress or completion state (no localStorage usage found in any docs/assets/js/*.js file), no in-product feedback path from an activity back to the repo (docs/assets/js/challenge.js has no issues/new or feedback link), and no way to bookmark/resume individual work outside the "set" mechanism, which is a one-way share link, not a personal tracker.

Top 5 next features

1. Area: Learner progress tracking

• Opportunity: Let a user mark activities complete and see progress across a module or custom set.
• User story: As a delivery team member working through a module, I want to mark activities as done and see my percent complete, so that I can track progress across multiple sessions without re-reading the catalog each time.
• Evidence: No localStorage/sessionStorage calls exist in docs/assets/js/challenge.js, catalog.js, module.js, or set.js; the only "progress" indicator is a static section counter in docs/assets/js/challenge.js:487 (guideSectionProgress), which tracks reading position within one guide, not completion.
• User value: Turns a one-time reference site into a resumable working tool, which matches the README's stated goal that "the result keeps running in production after the session."
• Implementation considerations: Purely client-side (localStorage), no backend needed; add UI in docs/challenge.html/catalog.html and rendering logic in docs/assets/js/challenge.js and catalog.js. Does not affect the build pipeline or meta.yml contract.
• Effort: Medium
• Priority: P1

2. Area: Feedback loop from activity to maintainers

• Opportunity: Add a "report an issue with this activity" link on each challenge page.
• User story: As someone delivering a session, I want to flag a broken or outdated activity from the page I'm on, so that maintainers learn about content problems without me finding the right file in modules/.
• Evidence: No feedback/issue link exists in docs/challenge.html or docs/assets/js/challenge.js; the repo already has source_repo/source_path fields in every meta.yml (per CONTRIBUTING.md) that could pre-fill a prefilled GitHub issue URl.
• User value: Converts silent friction into visible, actionable maintenance signal, improving content quality over time.
• Implementation considerations: Client-side only — build a github.com/.../issues/new?title=...&body=... link using the challenge's id/source_path (already in docs/assets/data/platform.json); render in docs/assets/js/challenge.js.
• Effort: Small
• Priority: P1

3. Area: Set builder persistence

• Opportunity: Let a facilitator save/reopen a set they built, not just share it once.
• User story: As a facilitator preparing a session, I want to save my in-progress custom set and come back to edit it later, so that I don't lose selections if I close the tab before generating a link.
• Evidence: docs/assets/js/builder.js builds a shareable link on demand (docs/builder.html:112 "Generate link") but has no save/restore of in-progress selections; docs/assets/js/set.js only consumes a ?ids= link, it doesn't let the viewer edit and re-save.
• User value: Reduces re-work for repeat facilitators building similar sets across sessions.
• Implementation considerations: Client-side localStorage for draft state in docs/assets/js/builder.js; optionally add an "edit this set" link from set.html back into builder.html pre-populated with ?ids=.
• Effort: Small
• Priority: P2

4. Area: Cross-outcome/module search discoverability**

• Opportunity: Surface full-text search across activity README content, not just catalog metadata fields.
• User story: As a user looking for a specific technique (for example "installation token"), I want to search guide content, so that I find the right activity even when the term isn't in the title, description, or tags.
• Evidence: docs/assets/js/catalog.js filters only on c.difficulty, tags, and metadata fields (catalog.js:202-222); full guide bodies are copied to docs/assets/data/challenges/<id>/README.md per the architecture diagram in README.md, but that content isn't indexed for search.
• User value: Faster activity discovery in a growing 87-activity catalog.
• Implementation considerations: Requires a small build-time step in docs/build.js to emit a lightweight search index (or lean on already-generated README files with a client-side fetch+search); UI change limited to catalog.js.
• Effort: Medium
• Priority: P2

5. Area: Operational handover / facilitator readiness checklist

• Opportunity: Combine the existing doctor.sh/verify-external-repos.js checks into a single pre-session readiness view in the UI.
• User story: As a facilitator prepping a live session, I want one place that confirms my environment (submodules fetched, external repo pins matching) is ready, so that I don't discover a missing dependency mid-session.
• Evidence: scripts/doctor.sh and scripts/verify-external-repos.js exist and run standalone via npm run verify:repos, but there is no UI surfacing of readiness state; docs/EXTERNAL-REPOS.md documents manual steps (npm run setup:juice-shop, npm run setup:sre-agent-lab) a facilitator must remember to run.
• User value: Reduces mid-session failures caused by unmet local prerequisites.
• Implementation considerations: This is a CLI-only workflow today; turning it into a UI feature would need a documented manual step (script output) rather than in-browser detection, since Pages is static and can't run local scripts. Consider instead a documentation callout or pre-flight checklist page rather than a live UI check.
• Effort: Medium
• Priority: P3

Quick UX wins

• Add a "copy activity ID" or direct link affordance next to each activity card in docs/assets/js/catalog.js, since IDs (ghec-ch01 etc.) are the durable reference unit used across outcomes.json, meta.yml, and the builder's ?ids= links, but no one-click copy exists today.
• In docs/assets/js/set.js, the generated set page has no "edit this set" link back to builder.html?ids=...; viewers who want to tweak a shared set must manually reconstruct the builder URL.

Not recommended yet

• Multi-tenant / hosted delivery-tracking backend — no evidence of any backend or auth in the repo (Pages is static, app is a submodule symlink to Juice Shop); this is out of scope for a GitHub Pages-only site and would be a major architecture change.
• In-browser environment provisioning (running setup:juice-shop from a button in the UI) — infeasible for a static Pages site; the existing script-based flow in scripts/provision-app.sh is the correct pattern given the constraints.
• Automated content freshness scanning against live GitHub features — scripts/audit-content.js already supports --external/--terminology checks; expanding this is an audit-quality improvement, not a new user-facing feature, and isn't tracked as a gap here.

Generated by Next Feature Opportunities · copilot · auto · 42.3 AIC · ⌖ 5.32 AIC · ⊞ 8.2K · ◷

This issue lists five possible features rather than one scoped change. Start by reading docs/build.js and the relevant entry points named for the selected opportunity, such as docs/assets/js/challenge.js, catalog.js, builder.js, or set.js. Done should mean one opportunity is chosen, its scope and acceptance criteria are documented, and the affected static pages work accordingly.