Define cost vs requirement semantics + UI for resource-gated story choices (no M1 content yet).
Context
During the PR3 T3.0 view-model review (story column projection), a design question surfaced: how should a story choice that requires/consumes resources behave?
Today isStoryChoiceAvailable only checks node membership + choice requirements; Story-kind actions in the Play column hide when their choice isn't available. There is no defined semantics for a choice that should be gated by (or spend) resources, and no M1 content currently uses one — so it is unspecified rather than broken.
Decide
Do resource-gated choices cost resources (deducted on pick) or merely require a threshold (visible-but-disabled until met)?
How is the gate authored in storySchema (choice requirements / outcomes)?
UI affordance in the Story column: hidden vs shown-disabled-with-reason (current story actions pass disabledReason: null).
Low priority: capture the rule before content authoring leans on it. Design intent should also land in the Obsidian vault (Idlegame/Decisions.md).
<brief>Define cost vs requirement semantics + UI for resource-gated story choices (no M1 content yet).</brief>
## Context
During the PR3 T3.0 view-model review (story column projection), a design question surfaced: how should a story **choice** that requires/consumes resources behave?
Today `isStoryChoiceAvailable` only checks node membership + choice requirements; Story-kind actions in the Play column hide when their choice isn't available. There is no defined semantics for a choice that should be gated by (or spend) resources, and no M1 content currently uses one — so it is unspecified rather than broken.
## Decide
- Do resource-gated choices **cost** resources (deducted on pick) or merely **require** a threshold (visible-but-disabled until met)?
- How is the gate authored in `storySchema` (choice `requirements` / outcomes)?
- UI affordance in the Story column: hidden vs shown-disabled-with-reason (current story actions pass `disabledReason: null`).
## Notes
- Related code: `src/engine/story.ts` (`isStoryChoiceAvailable`, choice requirements), `src/state/viewModel.ts` (story-kind availability projection), `src/content/storySchema.ts`.
- Low priority: capture the rule before content authoring leans on it. Design intent should also land in the Obsidian vault (`Idlegame/Decisions.md`).
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Define cost vs requirement semantics + UI for resource-gated story choices (no M1 content yet).
Context
During the PR3 T3.0 view-model review (story column projection), a design question surfaced: how should a story choice that requires/consumes resources behave?
Today
isStoryChoiceAvailableonly checks node membership + choice requirements; Story-kind actions in the Play column hide when their choice isn't available. There is no defined semantics for a choice that should be gated by (or spend) resources, and no M1 content currently uses one — so it is unspecified rather than broken.Decide
storySchema(choicerequirements/ outcomes)?disabledReason: null).Notes
src/engine/story.ts(isStoryChoiceAvailable, choice requirements),src/state/viewModel.ts(story-kind availability projection),src/content/storySchema.ts.Idlegame/Decisions.md).