@plasius/learning 0.6.0 → 0.7.0

package/dist/courses/vibe-idea-studio.d.cts

@@ -0,0 +1,8 @@
+import { L as LearningCourseV1, C as CoursePracticeQuestion } from '../course-authoring-DImvrK5r.cjs';
+import { L as LearningCourseSuggestionV1 } from '../course-suggestions-mK2MPB7e.cjs';
+
+declare const course: LearningCourseV1;
+declare const practice: CoursePracticeQuestion[];
+declare const suggestions: LearningCourseSuggestionV1[];
+
+export { course, practice, suggestions };

package/dist/courses/vibe-idea-studio.d.ts

@@ -0,0 +1,8 @@
+import { L as LearningCourseV1, C as CoursePracticeQuestion } from '../course-authoring-DImvrK5r.js';
+import { L as LearningCourseSuggestionV1 } from '../course-suggestions-CBs5swU6.js';
+
+declare const course: LearningCourseV1;
+declare const practice: CoursePracticeQuestion[];
+declare const suggestions: LearningCourseSuggestionV1[];
+
+export { course, practice, suggestions };

package/dist/courses/vibe-idea-studio.js

@@ -0,0 +1,191 @@
+import {
+  authorCourse
+} from "../chunk-2UIOBMJZ.js";
+import "../chunk-OXWMIHYI.js";
+
+// src/courses/vibe-idea-studio.ts
+var { course, practice } = authorCourse({
+  slug: "vibe-idea-studio",
+  title: "Vibe Idea Studio",
+  category: "vibe",
+  summary: "Turn a fictional audience's idea into an interactive mission board with a thirty-minute planning budget. Write executable success cases before completing the prototype, then add reversible completion, filtering and clear feedback. Finish a working private showcase with evidence for your design choices. Authored review examples make live AI unnecessary.",
+  projectFiles: [{ path: "app.js", language: "javascript", maximumCharacters: 32e3 }, { path: "brief.json", language: "json", maximumCharacters: 6e3 }],
+  starterProject: { files: [{ path: "app.js", source: `function initialState() {
+  return { title: "Rescue Mission Board", cards: [
+    { id: "scout", title: "Scout the path", minutes: 5, done: false },
+    { id: "signal", title: "Send a beacon", minutes: 10, done: false },
+    { id: "rescue", title: "Bring the team home", minutes: 15, done: false }
+  ], selectedId: null, remaining: 30, spent: 0, history: [], filter: "all", message: "Choose a mission." };
+}
+
+function update(state, input) {
+  if (input.type === "reset") return initialState();
+  return JSON.parse(JSON.stringify(state));
+}
+
+function view(state) { return {}; }
+function acceptanceCases() { return []; }
+` }, { path: "brief.json", source: '{\n  "audience": "",\n  "goal": "",\n  "constraints": []\n}\n' }] },
+  reference: [
+    { name: "initialState", signature: "initialState() \u2192 mission board", description: "A fresh board has an authored title of 3\u201360 characters, three to five uniquely identified fictional cards, no selection or history, 30 remaining minutes, zero spent, all filter and a useful message. Each card has id, title, integer minutes 1\u201330 and done=false. IDs use lowercase letters, digits and hyphens, 1\u201332 characters; titles use 3\u201360 characters.", example: '{ id: "scout", title: "Scout the path", minutes: 5, done: false }' },
+    { name: "update", signature: "update(state, input) \u2192 detached next state", description: "Actions are select with id, complete, undo, filter with value all/open/done, and reset. Unknown actions, unknown IDs and selection of a currently hidden card preserve values. Complete requires a selected visible unfinished card whose minutes fit remaining time; success marks it done, accounts minutes, records a receipt and clears selection. Feedback messages are nonempty text up to 200 characters.", example: 'update(state, { type: "select", id: "scout" });' },
+    { name: "time budget", signature: "remaining + spent === 30", description: "Completion subtracts the selected card's minutes from remaining and adds exactly that amount to spent. Missing selection, already-done cards and insufficient time change only the feedback message. Keep both counters within 0\u201330. A repeated complete cannot charge twice.", example: 'if (card.minutes > next.remaining) { next.message = "Not enough time remains."; return next; }' },
+    { name: "undo", signature: "history: [{ cardId, minutes }]", description: "Each successful completion appends a receipt with that card's ID and charged minutes, at most five entries. Undo removes the newest receipt, marks only that card unfinished, refunds its exact minutes and clears selection. Empty undo changes only feedback. Reset creates fresh cards, counters, selection and history.", example: "const receipt = next.history.pop(); next.remaining += receipt.minutes; next.spent -= receipt.minutes;" },
+    { name: "filter", signature: 'input: { type: "filter", value: "all" | "open" | "done" }', description: "A valid filter action records the filter and clears selection. Filtering changes no card, time counter or history entry. Unknown filters preserve state. view projects the appropriate cards while reporting counts from the complete card list.", example: 'const visible = state.cards.filter(card => state.filter === "all" || (state.filter === "done" ? card.done : !card.done));' },
+    { name: "view", signature: "view(state) \u2192 safe display data", description: "Return title, visibleCards [{id,title,minutes,done,selected}], completedCount, totalCount, remaining, spent, canComplete, canUndo and message. canComplete requires the selected visible unfinished card to fit the budget; canUndo means history is nonempty. Compute data without mutation. The host renders semantic controls and text; learner source has no DOM or network access.", example: "const completedCount = state.cards.filter(card => card.done).length;" },
+    { name: "brief.json", signature: "{ audience, goal, constraints }", description: "Write fictional audience and goal text, each 10\u2013160 characters, plus three to six constraints of 10\u2013160 characters. State the planning purpose, finite time budget, understandable feedback and ability to revise a choice. Labels can express your theme while the interaction contract remains testable.", example: '{ "audience": "A fictional rescue planning team", "goal": "Choose useful missions within thirty minutes", "constraints": ["Never spend more than the available time", "Make completed choices reversible", "Explain why an action cannot proceed"] }' },
+    { name: "acceptanceCases", signature: "acceptanceCases() \u2192 4\u20138 named replay cases", description: "Each case has name (3\u201360 characters), actions (1\u201340 documented actions) and expected {remaining,spent,doneIds,selectedId,historyCount,filter}. Start from initialState; doneIds follows card order. Include successful completion, repeated completion, undo and reset; add a filter case when implementing filters. During the test-first mission, the host verifies expected cases against the documented reference behaviour before the learner prototype implements it.", example: '{ name: "Complete scout", actions: [{type:"select",id:"scout"},{type:"complete"}], expected: {remaining:25,spent:5,doneIds:["scout"],selectedId:null,historyCount:1,filter:"all"} }' }
+  ]
+}, [
+  {
+    title: "Give the idea an audience",
+    concepts: ["Audience", "Purpose", "State and presentation"],
+    goals: ["Write a bounded fictional planning brief and a useful initial board.", "Expose truthful display data with labels and counts derived from state."],
+    extension: "Describe a second audience who could use the same interaction rules. Change the fictional labels in a separate version and explain what stayed reusable.",
+    activities: {
+      learn: ["An idea becomes actionable when you can name who it helps and what they need to do. This prototype helps a fictional team choose missions within thirty minutes. Start with a clear title, three to five labelled cards and truthful counts before adding completion controls.", "The starter's three cards offer a concrete beginning; your brief and labels can give the same bounded interaction an original theme."],
+      predict: ["Predict the initial completed count, remaining time and available actions. Compare canComplete with canUndo when there is no selection and no history, even though useful mission cards are visible.", "Visible opportunities do not automatically mean a particular action currently has valid prerequisites."],
+      build: ["Complete brief.json with an audience, goal and specific constraints. Author the board title and card labels, keeping valid unique IDs and bounded minutes. Implement view to return the documented data from state, with all cards initially visible and both action permissions false.", "A display projection reads state; it must not mark a card complete or alter the planning budget."],
+      run: ["Open the private board and inspect its title, cards, time and counts. Compare visible text with view output and restart from initialState. Check the labels with keyboard navigation and without relying on decoration.", "This is an interactive prototype in progress; later missions make its controls perform the planned actions."],
+      assess: ["Check initial card bounds and identities, fresh state, authored brief and truthful view projection. Confirm reading view changes no state and that counts describe the complete card list.", "A renamed title alone does not satisfy the data and accessibility requirements of a useful initial board."],
+      inspect: ["If counts disagree, inspect their source arrays. If action buttons appear enabled before selection or history exists, inspect their prerequisites. If one card replaces another, inspect duplicate IDs before blaming the display.", "Stable identities let later events refer to the intended card without depending on its label or position."],
+      fix: ["Repair the projection or initial data and compare fresh boards again. Keep your brief within the agreed scope and make sure every displayed action has an understandable label and state.", "Use fictional examples instead of adding personal details that the project does not need."],
+      explain: ["Choose the brief that names an observable user goal and explain how one display field supports it. Distinguish the idea's theme from the interaction rules that make it usable.", "The audience and goal help you decide which changes matter, rather than collecting unrelated features."],
+      reward: ["Save Defined audience. Your prototype now has a purpose and an honest initial view. Next you will write executable success cases before filling in its main interaction logic.", "Keep the initial board as a baseline for your later design decisions."]
+    },
+    questions: {
+      learn: { question: "Which statement defines a useful bounded prototype goal?", choices: ["Help a fictional team choose missions within thirty minutes", "Add every possible feature", "Make an unspecified audience impressed"], correctChoice: 0, feedback: "The statement identifies an audience, a concrete task and a finite resource that can guide implementation and tests." },
+      predict: { question: "With no selected card and empty history, which actions should be enabled?", choices: ["Complete and undo", "Neither complete nor undo", "Undo only"], correctChoice: 1, feedback: "Completion needs an eligible selection and undo needs a receipt, so neither has its prerequisite in the fresh board." },
+      explain: { question: "Why do cards need stable unique IDs as well as labels?", choices: ["To hide their titles", "To prevent any future edits", "So actions can identify the intended card reliably"], correctChoice: 2, feedback: "An identity lets selection and completion target the right record even when a label or displayed order changes." }
+    }
+  },
+  {
+    title: "Make success executable",
+    concepts: ["Test-first design", "Acceptance cases", "Independent expectations"],
+    goals: ["Translate the brief into bounded executable input sequences and predicted results.", "Distinguish a valid test of future behaviour from a currently implemented feature."],
+    extension: "Write a case for an unaffordable mission using a later depleted budget. Explain which state fields must remain unchanged when the action is refused.",
+    activities: {
+      learn: ["A success case describes actions and an expected result from a fresh board. Complete one card, repeat a completion, undo and reset are useful cases. Write four to eight bounded cases before implementing these behaviours. The host checks the predictions against the course contract separately from the unfinished prototype.", "An expected failure against unfinished code is visible progress in test-first work, not evidence that the behaviour already works."],
+      predict: ["For the starter cards, select scout and complete it. Predict remaining=25, spent=5, doneIds=[scout], no selection and one history receipt. Then predict the effect of another complete without selecting a card.", "The repeated action may explain its refusal but must not charge another five minutes."],
+      build: ["Implement acceptanceCases with complete expected projections and short action sequences. Use your current card IDs and minute values. Include completion, a repeated request, undo and reset without calling update to calculate the expected answers.", "Computing expectations from the same implementation being tested would make its defects agree with themselves."],
+      run: ["Run the cases in the test-first view. Inspect the reference-contract result alongside the current prototype result and identify which behaviours are still unimplemented. Confirm that deliberately wrong expected arithmetic is rejected.", "The lesson assessment checks the quality of these executable predictions; it does not claim that unfinished controls passed gameplay checks."],
+      assess: ["Validate bounded names, actions and exact expected projections against the documented contract. Check meaningful completion, repeat, undo and reset scenarios with independent expected values.", "A case title alone is insufficient; its action sequence must actually exercise the claimed behaviour."],
+      inspect: ["If a predicted case fails the contract, trace its arithmetic and selection state by hand. If only the unfinished prototype fails, identify the missing behaviour instead of changing a correct expectation to match empty logic.", "Separate test errors from implementation gaps before making a repair."],
+      fix: ["Correct any mistaken case and rerun the contract comparison. Retain correct cases that currently fail against the prototype; those become the concrete implementation targets for the next mission.", "Passing this mission means your bounded specifications are correct, not that the whole application is finished."],
+      explain: ["Choose why independent expected results matter and explain one currently failing prototype case. Describe what new behaviour would make that case pass without weakening its requirement.", "A test is useful because it can disagree with the programme when the programme is wrong or incomplete."],
+      reward: ["Save Executable success. Your idea now has specific checks that can challenge an implementation. Next you will build the smallest useful selection-and-completion loop that makes those examples real.", "Keep the expected results fixed unless the written contract or your original reasoning was demonstrably wrong."]
+    },
+    questions: {
+      learn: { question: "How should expected results be produced for acceptance cases?", choices: ["By copying the unfinished update output", "From the documented rule and independent reasoning", "By choosing whichever value currently passes"], correctChoice: 1, feedback: "Independent expectations can reveal an implementation defect instead of simply reproducing the same incorrect calculation." },
+      predict: { question: "Complete a five-minute scout from thirty minutes; how much remains?", choices: ["Thirty minutes", "Five minutes", "Twenty-five minutes"], correctChoice: 2, feedback: "The completed card consumes exactly five minutes, leaving twenty-five and recording five as spent." },
+      explain: { question: "What does a correct case failing against unfinished code tell you?", choices: ["Which documented behaviour still needs implementation", "That the correct requirement must be removed", "That the whole project is already complete"], correctChoice: 0, feedback: "A valid failing case names an implementation gap and supplies a concrete target for the next development step." }
+    }
+  },
+  {
+    title: "Build the smallest useful board",
+    concepts: ["Events", "Preconditions", "Conservation"],
+    goals: ["Select and complete an eligible mission through real state transitions.", "Preserve the finite time budget and explain refused actions without hidden changes."],
+    extension: "Compare a small mission and a larger mission from the same remaining budget. Explain how eligibility can change without changing either card's identity or title.",
+    activities: {
+      learn: ["Selection records an existing card ID. Complete succeeds only for a selected unfinished card whose minutes fit the remaining budget. Mark it done, subtract and add the same minutes to the two counters, append a receipt and clear selection. Refused actions change only a useful message.", "The invariant remaining+spent=30 connects visible time to actual completed choices."],
+      predict: ["Select scout, complete it and press complete again. Predict cards, counters, selection and history after both actions. Then select an already-completed card and consider why its presence does not make it eligible again.", "Action availability should be derived from current state, not from whether a button was once enabled."],
+      build: ["Implement select and complete in update using a detached copy. Validate the selected record, done state and available time before effects. On success record {cardId,minutes}, clear selection and set a clear message. Derive canComplete and canUndo from the resulting state.", "Use one successful completion path so accounting, card state and the receipt cannot disagree."],
+      run: ["Complete several missions with keyboard and onscreen controls. Try no selection, an unknown ID, a done card and an unaffordable card. Compare the explanatory message with unchanged data on refused actions.", "A disabled or refused action should explain what prerequisite is missing rather than appear silently broken."],
+      assess: ["Check selection, exact-budget completion, repeat requests, insufficient time, unknown IDs, receipt bounds and input immutability. The completion-related acceptance cases should now pass against your prototype itself.", "The independent checks also exercise states beyond the default three-card example."],
+      inspect: ["If time is charged twice, inspect selection clearing and the done guard. If counters drift apart, inspect whether both use the same card minutes. If refusal alters cards or receipts, inspect effects placed before validation.", "Compare the whole transition, not only the message that claims it succeeded or failed."],
+      fix: ["Repair the responsible guard or accounting step and rerun successful, repeated and refused completions. Check view after each result so displayed permissions and counts follow actual state.", "Do not set counters to favourable constants; conserve the exact amount charged by each real completion."],
+      explain: ["Choose why preconditions come before effects and explain how a receipt records the completed change. Describe how your smallest useful board now serves the goal in the brief.", "A useful prototype completes one coherent user task before adding unrelated features."],
+      reward: ["Save Useful board. Your prototype can now turn a selection into a correctly accounted choice. Next you will make that choice reversible and review a proposed simplification that would break the refund rule.", "Keep the repeated-complete case as protection for future interaction changes."]
+    },
+    questions: {
+      learn: { question: "What must hold before a card can complete?", choices: ["Its label is the longest", "Any card was selected sometime earlier", "It is currently selected, unfinished and affordable"], correctChoice: 2, feedback: "Completion depends on the current selected record and its live eligibility, not on a past button state or presentation detail." },
+      predict: { question: "What should repeated complete without a fresh selection do to time counters?", choices: ["Leave them unchanged", "Charge the last card again", "Restore all thirty minutes"], correctChoice: 0, feedback: "The first success clears selection, so the repeated request fails its prerequisite and cannot change accounting." },
+      explain: { question: "Why validate before changing cards and counters?", choices: ["To make useful actions impossible", "So a refused action cannot leave partial effects", "To hide all feedback"], correctChoice: 1, feedback: "Checking prerequisites first keeps refused transitions from partially altering data before discovering that completion was invalid." }
+    }
+  },
+  {
+    title: "Review a reversible change",
+    concepts: ["Undo", "Receipts", "Source review"],
+    goals: ["Undo only the latest completion and refund its exact charged time.", "Reject a source shortcut that would erase earlier accounting."],
+    extension: "Complete two differently sized cards and undo them in reverse order. Explain why last-in-first-out receipts identify the correct card and refund at each step.",
+    activities: {
+      learn: ["Undo pops the newest completion receipt, marks that card unfinished, refunds its recorded minutes and clears selection. Earlier receipts and completed cards remain. An authored suggestion replaces the exact refund with remaining=30; inspect its effect after more than one completion.", "Reversibility needs enough information about the actual change, not a guess based on the current display."],
+      predict: ["Complete scout for five minutes and signal for ten. Predict remaining and spent after undoing signal. Compare the documented refund with the proposed reset to thirty while scout remains complete.", "The correct result retains five spent minutes: remaining is twenty-five, not thirty."],
+      build: ["Implement undo with the latest receipt and exact refund, preserving all earlier work. Review and reject the refund-everything diff with the two-card counterexample. Handle empty history with an explanatory message and no data change; keep reset as the separate full restart.", "Undo and reset are different actions. Sharing a label or shortcut must not make their effects indistinguishable."],
+      run: ["Complete two cards, undo once, undo again and try an empty undo. Compare counters, done states, history length and selected card after each action. Run the authored proposal comparison against the same sequence.", "The actual removed and added source lines should support the review decision, not just the proposal's intent text."],
+      assess: ["Check last-in-first-out reversal, exact refunds, preservation of earlier completions, selection clearing, empty history and repeatable re-completion. Verify the rejected proposal's reasoning and current-source undo cases.", "An accepted or rejected review choice alone cannot substitute for correct executable state transitions."],
+      inspect: ["If all time returns after one undo, inspect the actual refund expression. If the wrong card reopens, inspect the popped cardId. If previous completions disappear, inspect whether the code resets instead of reversing one receipt.", "Compare one receipt with its original effect to identify exactly what must be reversed."],
+      fix: ["Repair undo and replay two completions followed by one undo. Recheck repeated completion and a full reset so reversal does not weaken the earlier accounting or fresh-state rules.", "Do not alter the expected result merely to accommodate the rejected constant-refund shortcut."],
+      explain: ["Choose why an exact receipt is useful and explain the difference between reversing one action and starting over. Describe the concrete evidence that made the proposed simplification unacceptable.", "A small code change can break a conservation rule across several previously completed actions."],
+      reward: ["Save Reversible choices. Your prototype now lets a user revise one decision predictably. Next you will explore filtering and presentation trade-offs while preserving that underlying state.", "Keep the two-card undo case as a regression for all future budget changes."]
+    },
+    questions: {
+      learn: { question: "Which completion should undo reverse?", choices: ["The newest remaining receipt", "Every completed card at once", "Whichever card is currently first onscreen"], correctChoice: 0, feedback: "The receipt stack records completed actions in order, so undo reverses the most recent one still present." },
+      predict: { question: "After spending five and ten minutes, undo the ten-minute card; how much remains?", choices: ["Thirty minutes", "Twenty-five minutes", "Fifteen minutes"], correctChoice: 1, feedback: "Only ten minutes are refunded, leaving the earlier five-minute completion intact and twenty-five minutes available." },
+      explain: { question: "Why is setting remaining to thirty an incorrect undo shortcut?", choices: ["Because no action can ever restore time", "Because card titles must change too", "Because it refunds earlier completions that were not undone"], correctChoice: 2, feedback: "A constant reset loses the relationship between the latest receipt and the specific amount that action consumed." }
+    }
+  },
+  {
+    title: "Explore the trade-offs",
+    concepts: ["Filtering", "Derived views", "Accessible feedback"],
+    goals: ["Add all, open and done views without changing the underlying plan.", "Keep actions, counts and feedback understandable when the visible set changes."],
+    extension: "Compare an all-cards view with an open-only view for your audience. Explain what each makes easier to notice and which global information must remain visible in both.",
+    activities: {
+      learn: ["A filter changes the view, not the plan. Valid all/open/done actions clear selection but preserve cards, counters and history. Compute visibleCards from the filter while completedCount and totalCount use every card. Ignore attempts to select a hidden ID and derive action permissions from visible state.", "A smaller display should not silently erase work or leave an unseen card selected for completion."],
+      predict: ["Complete scout and switch to done. Predict visible cards, total count, completed count and remaining time. Switch to open and consider a select request for the now-hidden scout ID.", "The complete card list is unchanged even when the visible list becomes smaller."],
+      build: ["Implement filter actions, selection clearing and hidden-card refusal. Update view to return correct visible cards, selection markers and permissions. Add a filter acceptance case and keep useful messages for empty results and refused actions without altering accounting.", "Keep labels and status text meaningful; colour and animation can supplement the information but must not carry it alone."],
+      run: ["Use keyboard and onscreen controls to switch filters before and after completion and undo. Try an empty done view, a hidden ID and a filter change with a selection. Compare the board in narrow and reduced-motion views.", "The shared host provides semantic controls; your projection must supply accurate names, counts and enabled states."],
+      assess: ["Check all filter values, unknown filters, hidden selection, selection clearing and global counts. Ensure filtering changes neither budget nor history and undo remains correct regardless of the active view.", "Tests compare data before and after a view change to catch accidental destructive filtering."],
+      inspect: ["If completed cards disappear permanently, inspect whether filter rewrites state.cards. If totalCount changes with the view, inspect its source list. If an invisible selection remains actionable, inspect filter transitions and eligibility together.", "Distinguish changing what is shown from changing what exists in the user's plan."],
+      fix: ["Repair the projection or transition and replay complete, filter, undo and reset. Verify the same underlying plan returns when all is selected, and recheck earlier completion and refund cases.", "A visual improvement must preserve the working behaviour that makes the prototype useful."],
+      explain: ["Choose which data filtering should preserve and describe a trade-off between showing everything and reducing visible detail. Explain how truthful global counts help a user understand the hidden portion.", "A design choice can improve one task while making another less obvious; name the trade-off instead of claiming one view is always best."],
+      reward: ["Save Understandable views. Your board can show focused information without losing work. The final mission connects the brief, interactions, reversal and view choices into a working showcase.", "Keep the filter-after-undo case because it crosses both data and presentation behaviour."]
+    },
+    questions: {
+      learn: { question: "What should a filter action preserve?", choices: ["Only the title", "Cards, time counters and completion history", "An invisible active selection"], correctChoice: 1, feedback: "Filtering changes presentation while retaining the underlying plan and accounting; clearing selection prevents hidden actions." },
+      predict: { question: "One of three cards is done and the done filter is active; what is totalCount?", choices: ["One", "Zero", "Three"], correctChoice: 2, feedback: "totalCount describes the full plan, so it remains three even though only one card is currently visible." },
+      explain: { question: "Why avoid assigning filtered results back to state.cards?", choices: ["It would delete hidden records rather than merely hide them", "It would make the title longer", "Filters must never read card state"], correctChoice: 0, feedback: "A projection should leave the source records intact so changing the filter can reveal them again without losing work." }
+    }
+  },
+  {
+    title: "Show the working idea",
+    concepts: ["Showcase", "Evidence", "Scope and iteration"],
+    goals: ["Deliver a coherent private mission-board prototype that serves the written brief.", "Demonstrate normal and refused actions with current-source evidence and explain design trade-offs."],
+    extension: "Propose a new interaction in a separate save. State its audience benefit, budget and undo implications, and acceptance cases before changing the completed prototype.",
+    activities: {
+      learn: ["A working showcase demonstrates a user task and its limits. Your board has truthful initial data, selection, affordable completion, exact undo, filtering and reset. Connect these behaviours to the audience and goal, then show both successful actions and useful explanations when an action cannot proceed.", "An original theme is valuable when it supports a coherent interaction, not when it replaces the working prototype with static decoration."],
+      predict: ["Plan a demonstration that selects two cards, completes them, changes filter, undoes the latest choice and resets. Predict each budget, count and selection transition before presenting the result.", "Include at least one refused action so the demonstration covers more than the easiest successful path."],
+      build: ["Complete the authored title, fictional labels, brief and acceptance cases. Review update and view for one consistent set of rules, remove abandoned experiments and keep the exact refund and filter-preservation constraints visible in your explanation.", "The final prototype should fit the original bounded goal; save additional ideas for a separate iteration."],
+      run: ["Perform the demonstration with keyboard and onscreen controls. Check narrow layouts, reduced motion and readable text feedback. Save, reload and repeat the same input sequence to compare the current source's results.", "A completed simulator session and an earned course result are different records; reset affects the prototype without erasing learning progress."],
+      assess: ["Run final checks for initial bounds, selection eligibility, time conservation, refusal without partial effects, receipt order, exact undo, filtering, view truthfulness, input immutability and fresh reset. All implemented acceptance cases must now pass against the prototype itself.", "The earlier test-first milestone accepted correct predictions; the final milestone requires the promised behaviour to exist and work."],
+      inspect: ["Compare a failure with the brief and identify its first incorrect transition. Decide whether it comes from data, permission, accounting, undo or projection, using a small reproduction to avoid unrelated edits.", "A pleasant-looking final card cannot prove that earlier counters or receipts stayed correct."],
+      fix: ["Repair the responsible rule, replay its focused case and rerun the complete demonstration. Save a named final project and obtain a fresh assessment for that source before finishing.", "An assessment from a previous version cannot establish the correctness of a later source change."],
+      explain: ["Choose the evidence that establishes a working prototype and describe one trade-off in your interface. Explain why you rejected the refund shortcut and what another iteration would need to test before expanding the idea.", "Be precise about what the prototype demonstrates, including actions it intentionally refuses and features outside its scope."],
+      reward: ["Save Working idea and finish the final assessment. You have taken an audience need through executable success criteria, implementation, review and a usable private prototype. Replay a mission or explore another idea while retaining earned completion.", "Keep the tested version as a reference; authored material and account-bound saving support the course without a live AI service."]
+    },
+    questions: {
+      learn: { question: "What makes the final showcase a working prototype?", choices: ["Only an attractive title", "A confident idea with no actions", "Implemented interactions supported by verified scenarios"], correctChoice: 2, feedback: "A prototype demonstrates real behaviour through actions and evidence, rather than merely presenting an idea's appearance." },
+      predict: { question: "Which acceptance cases must pass against the learner's source at the final milestone?", choices: ["All of the implemented documented cases", "Only cases that never change state", "None, because earlier predictions were correct"], correctChoice: 0, feedback: "Correct test-first predictions become obligations for the completed implementation, so the final source must now satisfy them." },
+      explain: { question: "What should guide the next iteration after this bounded prototype?", choices: ["Adding unrelated features without tests", "A clear audience benefit, constraints and new acceptance evidence", "Removing useful failure feedback"], correctChoice: 1, feedback: "Another iteration should connect a defined benefit to scoped implementation and evidence, just as the current prototype does." }
+    }
+  }
+]);
+var suggestions = [{ stageId: "vibe-idea-studio.m4.build", proposal: {
+  id: "idea-refund-everything",
+  source: "authored-fallback",
+  intent: "Simplify restoring time when undoing the latest completed mission.",
+  constraints: ["Undo refunds only the latest receipt's charged minutes.", "Earlier completed missions and their spent time remain intact."],
+  permittedArtifactId: "app.js",
+  originalSnippet: "next.remaining += receipt.minutes;",
+  replacementSnippet: "next.remaining = 30;",
+  explanationPrompt: "After completing scout and signal, does this change preserve the five minutes still spent on scout?",
+  aiOptional: false,
+  learnerApprovalRequired: true,
+  alternatives: ["accept", "reject"]
+} }];
+export {
+  course,
+  practice,
+  suggestions
+};
+//# sourceMappingURL=vibe-idea-studio.js.map

package/dist/courses/vibe-idea-studio.js.map

@@ -0,0 +1 @@
+{"version":3,"sources":["../../src/courses/vibe-idea-studio.ts"],"sourcesContent":["import { authorCourse } from \"./course-authoring.js\";\nimport type { LearningCourseSuggestionV1 } from \"../course-suggestions.js\";\n\nexport const { course, practice } = authorCourse({\n  slug: \"vibe-idea-studio\", title: \"Vibe Idea Studio\", category: \"vibe\",\n  summary: \"Turn a fictional audience's idea into an interactive mission board with a thirty-minute planning budget. Write executable success cases before completing the prototype, then add reversible completion, filtering and clear feedback. Finish a working private showcase with evidence for your design choices. Authored review examples make live AI unnecessary.\",\n  projectFiles: [{ path: \"app.js\", language: \"javascript\", maximumCharacters: 32000 }, { path: \"brief.json\", language: \"json\", maximumCharacters: 6000 }],\n  starterProject: { files: [{ path: \"app.js\", source: `function initialState() {\n  return { title: \"Rescue Mission Board\", cards: [\n    { id: \"scout\", title: \"Scout the path\", minutes: 5, done: false },\n    { id: \"signal\", title: \"Send a beacon\", minutes: 10, done: false },\n    { id: \"rescue\", title: \"Bring the team home\", minutes: 15, done: false }\n  ], selectedId: null, remaining: 30, spent: 0, history: [], filter: \"all\", message: \"Choose a mission.\" };\n}\n\nfunction update(state, input) {\n  if (input.type === \"reset\") return initialState();\n  return JSON.parse(JSON.stringify(state));\n}\n\nfunction view(state) { return {}; }\nfunction acceptanceCases() { return []; }\n` }, { path: \"brief.json\", source: '{\\n  \"audience\": \"\",\\n  \"goal\": \"\",\\n  \"constraints\": []\\n}\\n' }] },\n  reference: [\n    { name: \"initialState\", signature: \"initialState() → mission board\", description: \"A fresh board has an authored title of 3–60 characters, three to five uniquely identified fictional cards, no selection or history, 30 remaining minutes, zero spent, all filter and a useful message. Each card has id, title, integer minutes 1–30 and done=false. IDs use lowercase letters, digits and hyphens, 1–32 characters; titles use 3–60 characters.\", example: '{ id: \"scout\", title: \"Scout the path\", minutes: 5, done: false }' },\n    { name: \"update\", signature: \"update(state, input) → detached next state\", description: \"Actions are select with id, complete, undo, filter with value all/open/done, and reset. Unknown actions, unknown IDs and selection of a currently hidden card preserve values. Complete requires a selected visible unfinished card whose minutes fit remaining time; success marks it done, accounts minutes, records a receipt and clears selection. Feedback messages are nonempty text up to 200 characters.\", example: 'update(state, { type: \"select\", id: \"scout\" });' },\n    { name: \"time budget\", signature: \"remaining + spent === 30\", description: \"Completion subtracts the selected card's minutes from remaining and adds exactly that amount to spent. Missing selection, already-done cards and insufficient time change only the feedback message. Keep both counters within 0–30. A repeated complete cannot charge twice.\", example: 'if (card.minutes > next.remaining) { next.message = \"Not enough time remains.\"; return next; }' },\n    { name: \"undo\", signature: \"history: [{ cardId, minutes }]\", description: \"Each successful completion appends a receipt with that card's ID and charged minutes, at most five entries. Undo removes the newest receipt, marks only that card unfinished, refunds its exact minutes and clears selection. Empty undo changes only feedback. Reset creates fresh cards, counters, selection and history.\", example: \"const receipt = next.history.pop(); next.remaining += receipt.minutes; next.spent -= receipt.minutes;\" },\n    { name: \"filter\", signature: 'input: { type: \"filter\", value: \"all\" | \"open\" | \"done\" }', description: \"A valid filter action records the filter and clears selection. Filtering changes no card, time counter or history entry. Unknown filters preserve state. view projects the appropriate cards while reporting counts from the complete card list.\", example: 'const visible = state.cards.filter(card => state.filter === \"all\" || (state.filter === \"done\" ? card.done : !card.done));' },\n    { name: \"view\", signature: \"view(state) → safe display data\", description: \"Return title, visibleCards [{id,title,minutes,done,selected}], completedCount, totalCount, remaining, spent, canComplete, canUndo and message. canComplete requires the selected visible unfinished card to fit the budget; canUndo means history is nonempty. Compute data without mutation. The host renders semantic controls and text; learner source has no DOM or network access.\", example: \"const completedCount = state.cards.filter(card => card.done).length;\" },\n    { name: \"brief.json\", signature: \"{ audience, goal, constraints }\", description: \"Write fictional audience and goal text, each 10–160 characters, plus three to six constraints of 10–160 characters. State the planning purpose, finite time budget, understandable feedback and ability to revise a choice. Labels can express your theme while the interaction contract remains testable.\", example: '{ \"audience\": \"A fictional rescue planning team\", \"goal\": \"Choose useful missions within thirty minutes\", \"constraints\": [\"Never spend more than the available time\", \"Make completed choices reversible\", \"Explain why an action cannot proceed\"] }' },\n    { name: \"acceptanceCases\", signature: \"acceptanceCases() → 4–8 named replay cases\", description: \"Each case has name (3–60 characters), actions (1–40 documented actions) and expected {remaining,spent,doneIds,selectedId,historyCount,filter}. Start from initialState; doneIds follows card order. Include successful completion, repeated completion, undo and reset; add a filter case when implementing filters. During the test-first mission, the host verifies expected cases against the documented reference behaviour before the learner prototype implements it.\", example: '{ name: \"Complete scout\", actions: [{type:\"select\",id:\"scout\"},{type:\"complete\"}], expected: {remaining:25,spent:5,doneIds:[\"scout\"],selectedId:null,historyCount:1,filter:\"all\"} }' },\n  ],\n}, [\n  {\n    title: \"Give the idea an audience\", concepts: [\"Audience\", \"Purpose\", \"State and presentation\"],\n    goals: [\"Write a bounded fictional planning brief and a useful initial board.\", \"Expose truthful display data with labels and counts derived from state.\"],\n    extension: \"Describe a second audience who could use the same interaction rules. Change the fictional labels in a separate version and explain what stayed reusable.\",\n    activities: {\n      learn: [\"An idea becomes actionable when you can name who it helps and what they need to do. This prototype helps a fictional team choose missions within thirty minutes. Start with a clear title, three to five labelled cards and truthful counts before adding completion controls.\", \"The starter's three cards offer a concrete beginning; your brief and labels can give the same bounded interaction an original theme.\"],\n      predict: [\"Predict the initial completed count, remaining time and available actions. Compare canComplete with canUndo when there is no selection and no history, even though useful mission cards are visible.\", \"Visible opportunities do not automatically mean a particular action currently has valid prerequisites.\"],\n      build: [\"Complete brief.json with an audience, goal and specific constraints. Author the board title and card labels, keeping valid unique IDs and bounded minutes. Implement view to return the documented data from state, with all cards initially visible and both action permissions false.\", \"A display projection reads state; it must not mark a card complete or alter the planning budget.\"],\n      run: [\"Open the private board and inspect its title, cards, time and counts. Compare visible text with view output and restart from initialState. Check the labels with keyboard navigation and without relying on decoration.\", \"This is an interactive prototype in progress; later missions make its controls perform the planned actions.\"],\n      assess: [\"Check initial card bounds and identities, fresh state, authored brief and truthful view projection. Confirm reading view changes no state and that counts describe the complete card list.\", \"A renamed title alone does not satisfy the data and accessibility requirements of a useful initial board.\"],\n      inspect: [\"If counts disagree, inspect their source arrays. If action buttons appear enabled before selection or history exists, inspect their prerequisites. If one card replaces another, inspect duplicate IDs before blaming the display.\", \"Stable identities let later events refer to the intended card without depending on its label or position.\"],\n      fix: [\"Repair the projection or initial data and compare fresh boards again. Keep your brief within the agreed scope and make sure every displayed action has an understandable label and state.\", \"Use fictional examples instead of adding personal details that the project does not need.\"],\n      explain: [\"Choose the brief that names an observable user goal and explain how one display field supports it. Distinguish the idea's theme from the interaction rules that make it usable.\", \"The audience and goal help you decide which changes matter, rather than collecting unrelated features.\"],\n      reward: [\"Save Defined audience. Your prototype now has a purpose and an honest initial view. Next you will write executable success cases before filling in its main interaction logic.\", \"Keep the initial board as a baseline for your later design decisions.\"],\n    },\n    questions: {\n      learn: { question: \"Which statement defines a useful bounded prototype goal?\", choices: [\"Help a fictional team choose missions within thirty minutes\", \"Add every possible feature\", \"Make an unspecified audience impressed\"], correctChoice: 0, feedback: \"The statement identifies an audience, a concrete task and a finite resource that can guide implementation and tests.\" },\n      predict: { question: \"With no selected card and empty history, which actions should be enabled?\", choices: [\"Complete and undo\", \"Neither complete nor undo\", \"Undo only\"], correctChoice: 1, feedback: \"Completion needs an eligible selection and undo needs a receipt, so neither has its prerequisite in the fresh board.\" },\n      explain: { question: \"Why do cards need stable unique IDs as well as labels?\", choices: [\"To hide their titles\", \"To prevent any future edits\", \"So actions can identify the intended card reliably\"], correctChoice: 2, feedback: \"An identity lets selection and completion target the right record even when a label or displayed order changes.\" },\n    },\n  },\n  {\n    title: \"Make success executable\", concepts: [\"Test-first design\", \"Acceptance cases\", \"Independent expectations\"],\n    goals: [\"Translate the brief into bounded executable input sequences and predicted results.\", \"Distinguish a valid test of future behaviour from a currently implemented feature.\"],\n    extension: \"Write a case for an unaffordable mission using a later depleted budget. Explain which state fields must remain unchanged when the action is refused.\",\n    activities: {\n      learn: [\"A success case describes actions and an expected result from a fresh board. Complete one card, repeat a completion, undo and reset are useful cases. Write four to eight bounded cases before implementing these behaviours. The host checks the predictions against the course contract separately from the unfinished prototype.\", \"An expected failure against unfinished code is visible progress in test-first work, not evidence that the behaviour already works.\"],\n      predict: [\"For the starter cards, select scout and complete it. Predict remaining=25, spent=5, doneIds=[scout], no selection and one history receipt. Then predict the effect of another complete without selecting a card.\", \"The repeated action may explain its refusal but must not charge another five minutes.\"],\n      build: [\"Implement acceptanceCases with complete expected projections and short action sequences. Use your current card IDs and minute values. Include completion, a repeated request, undo and reset without calling update to calculate the expected answers.\", \"Computing expectations from the same implementation being tested would make its defects agree with themselves.\"],\n      run: [\"Run the cases in the test-first view. Inspect the reference-contract result alongside the current prototype result and identify which behaviours are still unimplemented. Confirm that deliberately wrong expected arithmetic is rejected.\", \"The lesson assessment checks the quality of these executable predictions; it does not claim that unfinished controls passed gameplay checks.\"],\n      assess: [\"Validate bounded names, actions and exact expected projections against the documented contract. Check meaningful completion, repeat, undo and reset scenarios with independent expected values.\", \"A case title alone is insufficient; its action sequence must actually exercise the claimed behaviour.\"],\n      inspect: [\"If a predicted case fails the contract, trace its arithmetic and selection state by hand. If only the unfinished prototype fails, identify the missing behaviour instead of changing a correct expectation to match empty logic.\", \"Separate test errors from implementation gaps before making a repair.\"],\n      fix: [\"Correct any mistaken case and rerun the contract comparison. Retain correct cases that currently fail against the prototype; those become the concrete implementation targets for the next mission.\", \"Passing this mission means your bounded specifications are correct, not that the whole application is finished.\"],\n      explain: [\"Choose why independent expected results matter and explain one currently failing prototype case. Describe what new behaviour would make that case pass without weakening its requirement.\", \"A test is useful because it can disagree with the programme when the programme is wrong or incomplete.\"],\n      reward: [\"Save Executable success. Your idea now has specific checks that can challenge an implementation. Next you will build the smallest useful selection-and-completion loop that makes those examples real.\", \"Keep the expected results fixed unless the written contract or your original reasoning was demonstrably wrong.\"],\n    },\n    questions: {\n      learn: { question: \"How should expected results be produced for acceptance cases?\", choices: [\"By copying the unfinished update output\", \"From the documented rule and independent reasoning\", \"By choosing whichever value currently passes\"], correctChoice: 1, feedback: \"Independent expectations can reveal an implementation defect instead of simply reproducing the same incorrect calculation.\" },\n      predict: { question: \"Complete a five-minute scout from thirty minutes; how much remains?\", choices: [\"Thirty minutes\", \"Five minutes\", \"Twenty-five minutes\"], correctChoice: 2, feedback: \"The completed card consumes exactly five minutes, leaving twenty-five and recording five as spent.\" },\n      explain: { question: \"What does a correct case failing against unfinished code tell you?\", choices: [\"Which documented behaviour still needs implementation\", \"That the correct requirement must be removed\", \"That the whole project is already complete\"], correctChoice: 0, feedback: \"A valid failing case names an implementation gap and supplies a concrete target for the next development step.\" },\n    },\n  },\n  {\n    title: \"Build the smallest useful board\", concepts: [\"Events\", \"Preconditions\", \"Conservation\"],\n    goals: [\"Select and complete an eligible mission through real state transitions.\", \"Preserve the finite time budget and explain refused actions without hidden changes.\"],\n    extension: \"Compare a small mission and a larger mission from the same remaining budget. Explain how eligibility can change without changing either card's identity or title.\",\n    activities: {\n      learn: [\"Selection records an existing card ID. Complete succeeds only for a selected unfinished card whose minutes fit the remaining budget. Mark it done, subtract and add the same minutes to the two counters, append a receipt and clear selection. Refused actions change only a useful message.\", \"The invariant remaining+spent=30 connects visible time to actual completed choices.\"],\n      predict: [\"Select scout, complete it and press complete again. Predict cards, counters, selection and history after both actions. Then select an already-completed card and consider why its presence does not make it eligible again.\", \"Action availability should be derived from current state, not from whether a button was once enabled.\"],\n      build: [\"Implement select and complete in update using a detached copy. Validate the selected record, done state and available time before effects. On success record {cardId,minutes}, clear selection and set a clear message. Derive canComplete and canUndo from the resulting state.\", \"Use one successful completion path so accounting, card state and the receipt cannot disagree.\"],\n      run: [\"Complete several missions with keyboard and onscreen controls. Try no selection, an unknown ID, a done card and an unaffordable card. Compare the explanatory message with unchanged data on refused actions.\", \"A disabled or refused action should explain what prerequisite is missing rather than appear silently broken.\"],\n      assess: [\"Check selection, exact-budget completion, repeat requests, insufficient time, unknown IDs, receipt bounds and input immutability. The completion-related acceptance cases should now pass against your prototype itself.\", \"The independent checks also exercise states beyond the default three-card example.\"],\n      inspect: [\"If time is charged twice, inspect selection clearing and the done guard. If counters drift apart, inspect whether both use the same card minutes. If refusal alters cards or receipts, inspect effects placed before validation.\", \"Compare the whole transition, not only the message that claims it succeeded or failed.\"],\n      fix: [\"Repair the responsible guard or accounting step and rerun successful, repeated and refused completions. Check view after each result so displayed permissions and counts follow actual state.\", \"Do not set counters to favourable constants; conserve the exact amount charged by each real completion.\"],\n      explain: [\"Choose why preconditions come before effects and explain how a receipt records the completed change. Describe how your smallest useful board now serves the goal in the brief.\", \"A useful prototype completes one coherent user task before adding unrelated features.\"],\n      reward: [\"Save Useful board. Your prototype can now turn a selection into a correctly accounted choice. Next you will make that choice reversible and review a proposed simplification that would break the refund rule.\", \"Keep the repeated-complete case as protection for future interaction changes.\"],\n    },\n    questions: {\n      learn: { question: \"What must hold before a card can complete?\", choices: [\"Its label is the longest\", \"Any card was selected sometime earlier\", \"It is currently selected, unfinished and affordable\"], correctChoice: 2, feedback: \"Completion depends on the current selected record and its live eligibility, not on a past button state or presentation detail.\" },\n      predict: { question: \"What should repeated complete without a fresh selection do to time counters?\", choices: [\"Leave them unchanged\", \"Charge the last card again\", \"Restore all thirty minutes\"], correctChoice: 0, feedback: \"The first success clears selection, so the repeated request fails its prerequisite and cannot change accounting.\" },\n      explain: { question: \"Why validate before changing cards and counters?\", choices: [\"To make useful actions impossible\", \"So a refused action cannot leave partial effects\", \"To hide all feedback\"], correctChoice: 1, feedback: \"Checking prerequisites first keeps refused transitions from partially altering data before discovering that completion was invalid.\" },\n    },\n  },\n  {\n    title: \"Review a reversible change\", concepts: [\"Undo\", \"Receipts\", \"Source review\"],\n    goals: [\"Undo only the latest completion and refund its exact charged time.\", \"Reject a source shortcut that would erase earlier accounting.\"],\n    extension: \"Complete two differently sized cards and undo them in reverse order. Explain why last-in-first-out receipts identify the correct card and refund at each step.\",\n    activities: {\n      learn: [\"Undo pops the newest completion receipt, marks that card unfinished, refunds its recorded minutes and clears selection. Earlier receipts and completed cards remain. An authored suggestion replaces the exact refund with remaining=30; inspect its effect after more than one completion.\", \"Reversibility needs enough information about the actual change, not a guess based on the current display.\"],\n      predict: [\"Complete scout for five minutes and signal for ten. Predict remaining and spent after undoing signal. Compare the documented refund with the proposed reset to thirty while scout remains complete.\", \"The correct result retains five spent minutes: remaining is twenty-five, not thirty.\"],\n      build: [\"Implement undo with the latest receipt and exact refund, preserving all earlier work. Review and reject the refund-everything diff with the two-card counterexample. Handle empty history with an explanatory message and no data change; keep reset as the separate full restart.\", \"Undo and reset are different actions. Sharing a label or shortcut must not make their effects indistinguishable.\"],\n      run: [\"Complete two cards, undo once, undo again and try an empty undo. Compare counters, done states, history length and selected card after each action. Run the authored proposal comparison against the same sequence.\", \"The actual removed and added source lines should support the review decision, not just the proposal's intent text.\"],\n      assess: [\"Check last-in-first-out reversal, exact refunds, preservation of earlier completions, selection clearing, empty history and repeatable re-completion. Verify the rejected proposal's reasoning and current-source undo cases.\", \"An accepted or rejected review choice alone cannot substitute for correct executable state transitions.\"],\n      inspect: [\"If all time returns after one undo, inspect the actual refund expression. If the wrong card reopens, inspect the popped cardId. If previous completions disappear, inspect whether the code resets instead of reversing one receipt.\", \"Compare one receipt with its original effect to identify exactly what must be reversed.\"],\n      fix: [\"Repair undo and replay two completions followed by one undo. Recheck repeated completion and a full reset so reversal does not weaken the earlier accounting or fresh-state rules.\", \"Do not alter the expected result merely to accommodate the rejected constant-refund shortcut.\"],\n      explain: [\"Choose why an exact receipt is useful and explain the difference between reversing one action and starting over. Describe the concrete evidence that made the proposed simplification unacceptable.\", \"A small code change can break a conservation rule across several previously completed actions.\"],\n      reward: [\"Save Reversible choices. Your prototype now lets a user revise one decision predictably. Next you will explore filtering and presentation trade-offs while preserving that underlying state.\", \"Keep the two-card undo case as a regression for all future budget changes.\"],\n    },\n    questions: {\n      learn: { question: \"Which completion should undo reverse?\", choices: [\"The newest remaining receipt\", \"Every completed card at once\", \"Whichever card is currently first onscreen\"], correctChoice: 0, feedback: \"The receipt stack records completed actions in order, so undo reverses the most recent one still present.\" },\n      predict: { question: \"After spending five and ten minutes, undo the ten-minute card; how much remains?\", choices: [\"Thirty minutes\", \"Twenty-five minutes\", \"Fifteen minutes\"], correctChoice: 1, feedback: \"Only ten minutes are refunded, leaving the earlier five-minute completion intact and twenty-five minutes available.\" },\n      explain: { question: \"Why is setting remaining to thirty an incorrect undo shortcut?\", choices: [\"Because no action can ever restore time\", \"Because card titles must change too\", \"Because it refunds earlier completions that were not undone\"], correctChoice: 2, feedback: \"A constant reset loses the relationship between the latest receipt and the specific amount that action consumed.\" },\n    },\n  },\n  {\n    title: \"Explore the trade-offs\", concepts: [\"Filtering\", \"Derived views\", \"Accessible feedback\"],\n    goals: [\"Add all, open and done views without changing the underlying plan.\", \"Keep actions, counts and feedback understandable when the visible set changes.\"],\n    extension: \"Compare an all-cards view with an open-only view for your audience. Explain what each makes easier to notice and which global information must remain visible in both.\",\n    activities: {\n      learn: [\"A filter changes the view, not the plan. Valid all/open/done actions clear selection but preserve cards, counters and history. Compute visibleCards from the filter while completedCount and totalCount use every card. Ignore attempts to select a hidden ID and derive action permissions from visible state.\", \"A smaller display should not silently erase work or leave an unseen card selected for completion.\"],\n      predict: [\"Complete scout and switch to done. Predict visible cards, total count, completed count and remaining time. Switch to open and consider a select request for the now-hidden scout ID.\", \"The complete card list is unchanged even when the visible list becomes smaller.\"],\n      build: [\"Implement filter actions, selection clearing and hidden-card refusal. Update view to return correct visible cards, selection markers and permissions. Add a filter acceptance case and keep useful messages for empty results and refused actions without altering accounting.\", \"Keep labels and status text meaningful; colour and animation can supplement the information but must not carry it alone.\"],\n      run: [\"Use keyboard and onscreen controls to switch filters before and after completion and undo. Try an empty done view, a hidden ID and a filter change with a selection. Compare the board in narrow and reduced-motion views.\", \"The shared host provides semantic controls; your projection must supply accurate names, counts and enabled states.\"],\n      assess: [\"Check all filter values, unknown filters, hidden selection, selection clearing and global counts. Ensure filtering changes neither budget nor history and undo remains correct regardless of the active view.\", \"Tests compare data before and after a view change to catch accidental destructive filtering.\"],\n      inspect: [\"If completed cards disappear permanently, inspect whether filter rewrites state.cards. If totalCount changes with the view, inspect its source list. If an invisible selection remains actionable, inspect filter transitions and eligibility together.\", \"Distinguish changing what is shown from changing what exists in the user's plan.\"],\n      fix: [\"Repair the projection or transition and replay complete, filter, undo and reset. Verify the same underlying plan returns when all is selected, and recheck earlier completion and refund cases.\", \"A visual improvement must preserve the working behaviour that makes the prototype useful.\"],\n      explain: [\"Choose which data filtering should preserve and describe a trade-off between showing everything and reducing visible detail. Explain how truthful global counts help a user understand the hidden portion.\", \"A design choice can improve one task while making another less obvious; name the trade-off instead of claiming one view is always best.\"],\n      reward: [\"Save Understandable views. Your board can show focused information without losing work. The final mission connects the brief, interactions, reversal and view choices into a working showcase.\", \"Keep the filter-after-undo case because it crosses both data and presentation behaviour.\"],\n    },\n    questions: {\n      learn: { question: \"What should a filter action preserve?\", choices: [\"Only the title\", \"Cards, time counters and completion history\", \"An invisible active selection\"], correctChoice: 1, feedback: \"Filtering changes presentation while retaining the underlying plan and accounting; clearing selection prevents hidden actions.\" },\n      predict: { question: \"One of three cards is done and the done filter is active; what is totalCount?\", choices: [\"One\", \"Zero\", \"Three\"], correctChoice: 2, feedback: \"totalCount describes the full plan, so it remains three even though only one card is currently visible.\" },\n      explain: { question: \"Why avoid assigning filtered results back to state.cards?\", choices: [\"It would delete hidden records rather than merely hide them\", \"It would make the title longer\", \"Filters must never read card state\"], correctChoice: 0, feedback: \"A projection should leave the source records intact so changing the filter can reveal them again without losing work.\" },\n    },\n  },\n  {\n    title: \"Show the working idea\", concepts: [\"Showcase\", \"Evidence\", \"Scope and iteration\"],\n    goals: [\"Deliver a coherent private mission-board prototype that serves the written brief.\", \"Demonstrate normal and refused actions with current-source evidence and explain design trade-offs.\"],\n    extension: \"Propose a new interaction in a separate save. State its audience benefit, budget and undo implications, and acceptance cases before changing the completed prototype.\",\n    activities: {\n      learn: [\"A working showcase demonstrates a user task and its limits. Your board has truthful initial data, selection, affordable completion, exact undo, filtering and reset. Connect these behaviours to the audience and goal, then show both successful actions and useful explanations when an action cannot proceed.\", \"An original theme is valuable when it supports a coherent interaction, not when it replaces the working prototype with static decoration.\"],\n      predict: [\"Plan a demonstration that selects two cards, completes them, changes filter, undoes the latest choice and resets. Predict each budget, count and selection transition before presenting the result.\", \"Include at least one refused action so the demonstration covers more than the easiest successful path.\"],\n      build: [\"Complete the authored title, fictional labels, brief and acceptance cases. Review update and view for one consistent set of rules, remove abandoned experiments and keep the exact refund and filter-preservation constraints visible in your explanation.\", \"The final prototype should fit the original bounded goal; save additional ideas for a separate iteration.\"],\n      run: [\"Perform the demonstration with keyboard and onscreen controls. Check narrow layouts, reduced motion and readable text feedback. Save, reload and repeat the same input sequence to compare the current source's results.\", \"A completed simulator session and an earned course result are different records; reset affects the prototype without erasing learning progress.\"],\n      assess: [\"Run final checks for initial bounds, selection eligibility, time conservation, refusal without partial effects, receipt order, exact undo, filtering, view truthfulness, input immutability and fresh reset. All implemented acceptance cases must now pass against the prototype itself.\", \"The earlier test-first milestone accepted correct predictions; the final milestone requires the promised behaviour to exist and work.\"],\n      inspect: [\"Compare a failure with the brief and identify its first incorrect transition. Decide whether it comes from data, permission, accounting, undo or projection, using a small reproduction to avoid unrelated edits.\", \"A pleasant-looking final card cannot prove that earlier counters or receipts stayed correct.\"],\n      fix: [\"Repair the responsible rule, replay its focused case and rerun the complete demonstration. Save a named final project and obtain a fresh assessment for that source before finishing.\", \"An assessment from a previous version cannot establish the correctness of a later source change.\"],\n      explain: [\"Choose the evidence that establishes a working prototype and describe one trade-off in your interface. Explain why you rejected the refund shortcut and what another iteration would need to test before expanding the idea.\", \"Be precise about what the prototype demonstrates, including actions it intentionally refuses and features outside its scope.\"],\n      reward: [\"Save Working idea and finish the final assessment. You have taken an audience need through executable success criteria, implementation, review and a usable private prototype. Replay a mission or explore another idea while retaining earned completion.\", \"Keep the tested version as a reference; authored material and account-bound saving support the course without a live AI service.\"],\n    },\n    questions: {\n      learn: { question: \"What makes the final showcase a working prototype?\", choices: [\"Only an attractive title\", \"A confident idea with no actions\", \"Implemented interactions supported by verified scenarios\"], correctChoice: 2, feedback: \"A prototype demonstrates real behaviour through actions and evidence, rather than merely presenting an idea's appearance.\" },\n      predict: { question: \"Which acceptance cases must pass against the learner's source at the final milestone?\", choices: [\"All of the implemented documented cases\", \"Only cases that never change state\", \"None, because earlier predictions were correct\"], correctChoice: 0, feedback: \"Correct test-first predictions become obligations for the completed implementation, so the final source must now satisfy them.\" },\n      explain: { question: \"What should guide the next iteration after this bounded prototype?\", choices: [\"Adding unrelated features without tests\", \"A clear audience benefit, constraints and new acceptance evidence\", \"Removing useful failure feedback\"], correctChoice: 1, feedback: \"Another iteration should connect a defined benefit to scoped implementation and evidence, just as the current prototype does.\" },\n    },\n  },\n]);\n\nexport const suggestions: LearningCourseSuggestionV1[] = [{ stageId: \"vibe-idea-studio.m4.build\", proposal: {\n  id: \"idea-refund-everything\", source: \"authored-fallback\", intent: \"Simplify restoring time when undoing the latest completed mission.\",\n  constraints: [\"Undo refunds only the latest receipt's charged minutes.\", \"Earlier completed missions and their spent time remain intact.\"],\n  permittedArtifactId: \"app.js\", originalSnippet: \"next.remaining += receipt.minutes;\", replacementSnippet: \"next.remaining = 30;\",\n  explanationPrompt: \"After completing scout and signal, does this change preserve the five minutes still spent on scout?\",\n  aiOptional: false, learnerApprovalRequired: true, alternatives: [\"accept\", \"reject\"],\n} }];\n"],"mappings":";;;;;;AAGO,IAAM,EAAE,QAAQ,SAAS,IAAI,aAAa;AAAA,EAC/C,MAAM;AAAA,EAAoB,OAAO;AAAA,EAAoB,UAAU;AAAA,EAC/D,SAAS;AAAA,EACT,cAAc,CAAC,EAAE,MAAM,UAAU,UAAU,cAAc,mBAAmB,KAAM,GAAG,EAAE,MAAM,cAAc,UAAU,QAAQ,mBAAmB,IAAK,CAAC;AAAA,EACtJ,gBAAgB,EAAE,OAAO,CAAC,EAAE,MAAM,UAAU,QAAQ;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA;AAAA,EAepD,GAAG,EAAE,MAAM,cAAc,QAAQ,gEAAgE,CAAC,EAAE;AAAA,EACpG,WAAW;AAAA,IACT,EAAE,MAAM,gBAAgB,WAAW,uCAAkC,aAAa,wXAAoW,SAAS,oEAAoE;AAAA,IACngB,EAAE,MAAM,UAAU,WAAW,mDAA8C,aAAa,oZAAoZ,SAAS,kDAAkD;AAAA,IACviB,EAAE,MAAM,eAAe,WAAW,4BAA4B,aAAa,sRAAiR,SAAS,iGAAiG;AAAA,IACtc,EAAE,MAAM,QAAQ,WAAW,kCAAkC,aAAa,+TAA+T,SAAS,wGAAwG;AAAA,IAC1f,EAAE,MAAM,UAAU,WAAW,6DAA6D,aAAa,oPAAoP,SAAS,4HAA4H;AAAA,IAChe,EAAE,MAAM,QAAQ,WAAW,wCAAmC,aAAa,2XAA2X,SAAS,uEAAuE;AAAA,IACthB,EAAE,MAAM,cAAc,WAAW,mCAAmC,aAAa,wTAA8S,SAAS,uPAAuP;AAAA,IAC/nB,EAAE,MAAM,mBAAmB,WAAW,wDAA8C,aAAa,ydAA+c,SAAS,sLAAsL;AAAA,EACjvB;AACF,GAAG;AAAA,EACD;AAAA,IACE,OAAO;AAAA,IAA6B,UAAU,CAAC,YAAY,WAAW,wBAAwB;AAAA,IAC9F,OAAO,CAAC,wEAAwE,yEAAyE;AAAA,IACzJ,WAAW;AAAA,IACX,YAAY;AAAA,MACV,OAAO,CAAC,kRAAkR,sIAAsI;AAAA,MACha,SAAS,CAAC,wMAAwM,wGAAwG;AAAA,MAC1T,OAAO,CAAC,2RAA2R,kGAAkG;AAAA,MACrY,KAAK,CAAC,2NAA2N,6GAA6G;AAAA,MAC9U,QAAQ,CAAC,8LAA8L,2GAA2G;AAAA,MAClT,SAAS,CAAC,sOAAsO,2GAA2G;AAAA,MAC3V,KAAK,CAAC,6LAA6L,2FAA2F;AAAA,MAC9R,SAAS,CAAC,mLAAmL,wGAAwG;AAAA,MACrS,QAAQ,CAAC,kLAAkL,uEAAuE;AAAA,IACpQ;AAAA,IACA,WAAW;AAAA,MACT,OAAO,EAAE,UAAU,4DAA4D,SAAS,CAAC,+DAA+D,8BAA8B,wCAAwC,GAAG,eAAe,GAAG,UAAU,uHAAuH;AAAA,MACpX,SAAS,EAAE,UAAU,6EAA6E,SAAS,CAAC,qBAAqB,6BAA6B,WAAW,GAAG,eAAe,GAAG,UAAU,uHAAuH;AAAA,MAC/T,SAAS,EAAE,UAAU,0DAA0D,SAAS,CAAC,wBAAwB,+BAA+B,oDAAoD,GAAG,eAAe,GAAG,UAAU,kHAAkH;AAAA,IACvV;AAAA,EACF;AAAA,EACA;AAAA,IACE,OAAO;AAAA,IAA2B,UAAU,CAAC,qBAAqB,oBAAoB,0BAA0B;AAAA,IAChH,OAAO,CAAC,sFAAsF,oFAAoF;AAAA,IAClL,WAAW;AAAA,IACX,YAAY;AAAA,MACV,OAAO,CAAC,sUAAsU,oIAAoI;AAAA,MACld,SAAS,CAAC,oNAAoN,uFAAuF;AAAA,MACrT,OAAO,CAAC,0PAA0P,gHAAgH;AAAA,MAClX,KAAK,CAAC,8OAA8O,8IAA8I;AAAA,MAClY,QAAQ,CAAC,mMAAmM,uGAAuG;AAAA,MACnT,SAAS,CAAC,oOAAoO,uEAAuE;AAAA,MACrT,KAAK,CAAC,uMAAuM,iHAAiH;AAAA,MAC9T,SAAS,CAAC,6LAA6L,wGAAwG;AAAA,MAC/S,QAAQ,CAAC,0MAA0M,gHAAgH;AAAA,IACrU;AAAA,IACA,WAAW;AAAA,MACT,OAAO,EAAE,UAAU,iEAAiE,SAAS,CAAC,2CAA2C,sDAAsD,8CAA8C,GAAG,eAAe,GAAG,UAAU,6HAA6H;AAAA,MACzY,SAAS,EAAE,UAAU,uEAAuE,SAAS,CAAC,kBAAkB,gBAAgB,qBAAqB,GAAG,eAAe,GAAG,UAAU,qGAAqG;AAAA,MACjS,SAAS,EAAE,UAAU,sEAAsE,SAAS,CAAC,yDAAyD,gDAAgD,4CAA4C,GAAG,eAAe,GAAG,UAAU,iHAAiH;AAAA,IAC5Y;AAAA,EACF;AAAA,EACA;AAAA,IACE,OAAO;AAAA,IAAmC,UAAU,CAAC,UAAU,iBAAiB,cAAc;AAAA,IAC9F,OAAO,CAAC,2EAA2E,qFAAqF;AAAA,IACxK,WAAW;AAAA,IACX,YAAY;AAAA,MACV,OAAO,CAAC,iSAAiS,qFAAqF;AAAA,MAC9X,SAAS,CAAC,+NAA+N,uGAAuG;AAAA,MAChV,OAAO,CAAC,oRAAoR,+FAA+F;AAAA,MAC3X,KAAK,CAAC,iNAAiN,8GAA8G;AAAA,MACrU,QAAQ,CAAC,4NAA4N,oFAAoF;AAAA,MACzT,SAAS,CAAC,oOAAoO,wFAAwF;AAAA,MACtU,KAAK,CAAC,iMAAiM,yGAAyG;AAAA,MAChT,SAAS,CAAC,kLAAkL,uFAAuF;AAAA,MACnR,QAAQ,CAAC,kNAAkN,+EAA+E;AAAA,IAC5S;AAAA,IACA,WAAW;AAAA,MACT,OAAO,EAAE,UAAU,8CAA8C,SAAS,CAAC,4BAA4B,0CAA0C,qDAAqD,GAAG,eAAe,GAAG,UAAU,iIAAiI;AAAA,MACtW,SAAS,EAAE,UAAU,gFAAgF,SAAS,CAAC,wBAAwB,8BAA8B,4BAA4B,GAAG,eAAe,GAAG,UAAU,mHAAmH;AAAA,MACnV,SAAS,EAAE,UAAU,oDAAoD,SAAS,CAAC,qCAAqC,oDAAoD,sBAAsB,GAAG,eAAe,GAAG,UAAU,sIAAsI;AAAA,IACzW;AAAA,EACF;AAAA,EACA;AAAA,IACE,OAAO;AAAA,IAA8B,UAAU,CAAC,QAAQ,YAAY,eAAe;AAAA,IACnF,OAAO,CAAC,sEAAsE,+DAA+D;AAAA,IAC7I,WAAW;AAAA,IACX,YAAY;AAAA,MACV,OAAO,CAAC,+RAA+R,2GAA2G;AAAA,MAClZ,SAAS,CAAC,uMAAuM,sFAAsF;AAAA,MACvS,OAAO,CAAC,sRAAsR,kHAAkH;AAAA,MAChZ,KAAK,CAAC,uNAAuN,oHAAoH;AAAA,MACjV,QAAQ,CAAC,iOAAiO,yGAAyG;AAAA,MACnV,SAAS,CAAC,wOAAwO,yFAAyF;AAAA,MAC3U,KAAK,CAAC,sLAAsL,+FAA+F;AAAA,MAC3R,SAAS,CAAC,uMAAuM,gGAAgG;AAAA,MACjT,QAAQ,CAAC,gMAAgM,4EAA4E;AAAA,IACvR;AAAA,IACA,WAAW;AAAA,MACT,OAAO,EAAE,UAAU,yCAAyC,SAAS,CAAC,gCAAgC,gCAAgC,4CAA4C,GAAG,eAAe,GAAG,UAAU,4GAA4G;AAAA,MAC7T,SAAS,EAAE,UAAU,oFAAoF,SAAS,CAAC,kBAAkB,uBAAuB,iBAAiB,GAAG,eAAe,GAAG,UAAU,sHAAsH;AAAA,MAClU,SAAS,EAAE,UAAU,kEAAkE,SAAS,CAAC,2CAA2C,uCAAuC,6DAA6D,GAAG,eAAe,GAAG,UAAU,mHAAmH;AAAA,IACpY;AAAA,EACF;AAAA,EACA;AAAA,IACE,OAAO;AAAA,IAA0B,UAAU,CAAC,aAAa,iBAAiB,qBAAqB;AAAA,IAC/F,OAAO,CAAC,sEAAsE,gFAAgF;AAAA,IAC9J,WAAW;AAAA,IACX,YAAY;AAAA,MACV,OAAO,CAAC,mTAAmT,mGAAmG;AAAA,MAC9Z,SAAS,CAAC,wLAAwL,iFAAiF;AAAA,MACnR,OAAO,CAAC,kRAAkR,0HAA0H;AAAA,MACpZ,KAAK,CAAC,8NAA8N,oHAAoH;AAAA,MACxV,QAAQ,CAAC,iNAAiN,8FAA8F;AAAA,MACxT,SAAS,CAAC,2PAA2P,kFAAkF;AAAA,MACvV,KAAK,CAAC,mMAAmM,2FAA2F;AAAA,MACpS,SAAS,CAAC,8MAA8M,yIAAyI;AAAA,MACjW,QAAQ,CAAC,kMAAkM,0FAA0F;AAAA,IACvS;AAAA,IACA,WAAW;AAAA,MACT,OAAO,EAAE,UAAU,yCAAyC,SAAS,CAAC,kBAAkB,+CAA+C,+BAA+B,GAAG,eAAe,GAAG,UAAU,iIAAiI;AAAA,MACtU,SAAS,EAAE,UAAU,iFAAiF,SAAS,CAAC,OAAO,QAAQ,OAAO,GAAG,eAAe,GAAG,UAAU,0GAA0G;AAAA,MAC/Q,SAAS,EAAE,UAAU,6DAA6D,SAAS,CAAC,+DAA+D,kCAAkC,oCAAoC,GAAG,eAAe,GAAG,UAAU,wHAAwH;AAAA,IAC1X;AAAA,EACF;AAAA,EACA;AAAA,IACE,OAAO;AAAA,IAAyB,UAAU,CAAC,YAAY,YAAY,qBAAqB;AAAA,IACxF,OAAO,CAAC,qFAAqF,oGAAoG;AAAA,IACjM,WAAW;AAAA,IACX,YAAY;AAAA,MACV,OAAO,CAAC,oTAAoT,2IAA2I;AAAA,MACvc,SAAS,CAAC,uMAAuM,wGAAwG;AAAA,MACzT,OAAO,CAAC,8PAA8P,2GAA2G;AAAA,MACjX,KAAK,CAAC,4NAA4N,iJAAiJ;AAAA,MACnX,QAAQ,CAAC,6RAA6R,uIAAuI;AAAA,MAC7a,SAAS,CAAC,qNAAqN,8FAA8F;AAAA,MAC7T,KAAK,CAAC,yLAAyL,kGAAkG;AAAA,MACjS,SAAS,CAAC,gOAAgO,8HAA8H;AAAA,MACxW,QAAQ,CAAC,8PAA8P,kIAAkI;AAAA,IAC3Y;AAAA,IACA,WAAW;AAAA,MACT,OAAO,EAAE,UAAU,sDAAsD,SAAS,CAAC,4BAA4B,oCAAoC,0DAA0D,GAAG,eAAe,GAAG,UAAU,4HAA4H;AAAA,MACxW,SAAS,EAAE,UAAU,yFAAyF,SAAS,CAAC,2CAA2C,sCAAsC,gDAAgD,GAAG,eAAe,GAAG,UAAU,iIAAiI;AAAA,MACzZ,SAAS,EAAE,UAAU,sEAAsE,SAAS,CAAC,2CAA2C,qEAAqE,kCAAkC,GAAG,eAAe,GAAG,UAAU,gIAAgI;AAAA,IACxZ;AAAA,EACF;AACF,CAAC;AAEM,IAAM,cAA4C,CAAC,EAAE,SAAS,6BAA6B,UAAU;AAAA,EAC1G,IAAI;AAAA,EAA0B,QAAQ;AAAA,EAAqB,QAAQ;AAAA,EACnE,aAAa,CAAC,2DAA2D,gEAAgE;AAAA,EACzI,qBAAqB;AAAA,EAAU,iBAAiB;AAAA,EAAsC,oBAAoB;AAAA,EAC1G,mBAAmB;AAAA,EACnB,YAAY;AAAA,EAAO,yBAAyB;AAAA,EAAM,cAAc,CAAC,UAAU,QAAQ;AACrF,EAAE,CAAC;","names":[]}

package/dist/index.cjs

@@ -68,6 +68,7 @@ __export(index_exports, {
   VIBE_BUG_DETECTIVE_MISSION_ONE_AUTHORING_V1: () => VIBE_BUG_DETECTIVE_MISSION_ONE_AUTHORING_V1,
   VIBE_GAME_REMIX_LAB_MISSION_ONE_AUTHORING_V1: () => VIBE_GAME_REMIX_LAB_MISSION_ONE_AUTHORING_V1,
   VIBE_IDEA_STUDIO_MISSION_ONE_AUTHORING_V1: () => VIBE_IDEA_STUDIO_MISSION_ONE_AUTHORING_V1,
+  applyLearningCourseSuggestion: () => applyLearningCourseSuggestion,
   assertValidCanonicalSpokenHelpDescriptor: () => assertValidCanonicalSpokenHelpDescriptor,
   assertValidContextualHelpIdentifier: () => assertValidContextualHelpIdentifier,
   assertValidContextualVoiceQuestionMetadata: () => assertValidContextualVoiceQuestionMetadata,
@@ -86,6 +87,7 @@ __export(index_exports, {
   parseLearningCourse: () => parseLearningCourse,
   parseLearningCourseDraft: () => parseLearningCourseDraft,
   parseLearningCourseProgress: () => parseLearningCourseProgress,
+  parseLearningCourseSuggestion: () => parseLearningCourseSuggestion,
   parseLearningProject: () => parseLearningProject,
   parseLearningSaveSlotId: () => parseLearningSaveSlotId,
   recordLearningCourseAssessment: () => recordLearningCourseAssessment,
@@ -6868,7 +6870,7 @@ var record = (value) => typeof value === "object" && value !== null && !Array.is
 var text = (value, minimum = 1, maximum = 8e3) => typeof value === "string" && value.trim().length >= minimum && value.length <= maximum;
 var id = (value) => typeof value === "string" && ID.test(value);
 var integer = (value, minimum, maximum) => typeof value === "number" && Number.isSafeInteger(value) && value >= minimum && value <= maximum;
-var exactKeys = (value, keys2) => Object.keys(value).length === keys2.length && keys2.every((key) => Object.hasOwn(value, key));
+var exactKeys = (value, keys3) => Object.keys(value).length === keys3.length && keys3.every((key) => Object.hasOwn(value, key));
 var LearningCourseInputError = class extends Error {
   constructor() {
     super("Invalid learning course input.");
@@ -7082,6 +7084,42 @@ function completeVerifiedLearningActivity(course, progress, proof) {
   return next;
 }
 
+// src/course-suggestions.ts
+var record3 = (value) => value !== null && typeof value === "object" && !Array.isArray(value);
+var keys2 = (value, expected) => Object.keys(value).length === expected.length && expected.every((key) => Object.hasOwn(value, key));
+var text2 = (value, maximum) => typeof value === "string" && value.trim().length > 0 && value.length <= maximum && !value.includes("\0");
+function parseLearningCourseSuggestion(course, value) {
+  if (!record3(value) || !keys2(value, ["stageId", "proposal"]) || !text2(value.stageId, 128) || !course.missions.some((mission2) => mission2.stages.some((stage) => stage.id === value.stageId)) || !record3(value.proposal)) {
+    throw new Error("Invalid course suggestion.");
+  }
+  const proposal = value.proposal;
+  if (!keys2(proposal, [
+    "id",
+    "source",
+    "intent",
+    "constraints",
+    "permittedArtifactId",
+    "originalSnippet",
+    "replacementSnippet",
+    "explanationPrompt",
+    "aiOptional",
+    "learnerApprovalRequired",
+    "alternatives"
+  ]) || !text2(proposal.id, 128) || proposal.source !== "authored-fallback" || !text2(proposal.intent, 1e3) || !Array.isArray(proposal.constraints) || proposal.constraints.length < 1 || proposal.constraints.length > 8 || !proposal.constraints.every((constraint) => text2(constraint, 400)) || !course.projectFiles.some((file) => file.path === proposal.permittedArtifactId) || !text2(proposal.originalSnippet, 8e3) || !text2(proposal.replacementSnippet, 8e3) || proposal.originalSnippet === proposal.replacementSnippet || !text2(proposal.explanationPrompt, 1e3) || proposal.aiOptional !== false || proposal.learnerApprovalRequired !== true || !Array.isArray(proposal.alternatives) || proposal.alternatives.length !== 2 || proposal.alternatives[0] !== "accept" || proposal.alternatives[1] !== "reject") throw new Error("Invalid course suggestion.");
+  return structuredClone(value);
+}
+function applyLearningCourseSuggestion(course, project, suggestion) {
+  const parsed = parseLearningProject(course, project);
+  const { proposal } = parseLearningCourseSuggestion(course, suggestion);
+  const file = parsed.files.find((candidate) => candidate.path === proposal.permittedArtifactId);
+  const start = file.source.indexOf(proposal.originalSnippet);
+  if (start < 0 || file.source.indexOf(proposal.originalSnippet, start + 1) >= 0) {
+    throw new Error("Suggestion does not match exactly one source location.");
+  }
+  file.source = file.source.slice(0, start) + proposal.replacementSnippet + file.source.slice(start + proposal.originalSnippet.length);
+  return parseLearningProject(course, parsed);
+}
+
 // src/contextual-help.ts
 var CONTEXTUAL_HELP_CONTRACT_VERSION_V1 = "1.0.0";
 var CONTEXTUAL_HELP_KINDS_V1 = Object.freeze([
@@ -7596,6 +7634,7 @@ ${summary}`);
   VIBE_BUG_DETECTIVE_MISSION_ONE_AUTHORING_V1,
   VIBE_GAME_REMIX_LAB_MISSION_ONE_AUTHORING_V1,
   VIBE_IDEA_STUDIO_MISSION_ONE_AUTHORING_V1,
+  applyLearningCourseSuggestion,
   assertValidCanonicalSpokenHelpDescriptor,
   assertValidContextualHelpIdentifier,
   assertValidContextualVoiceQuestionMetadata,
@@ -7614,6 +7653,7 @@ ${summary}`);
   parseLearningCourse,
   parseLearningCourseDraft,
   parseLearningCourseProgress,
+  parseLearningCourseSuggestion,
   parseLearningProject,
   parseLearningSaveSlotId,
   recordLearningCourseAssessment,