A workspace scenario cannot be run end to end from the CLI, and a task a scenario emits cannot complete on anything but a code diff. Both are needed before the quickstart in #4910 can be written against real command output.
All three findings below were checked against main at 453f8de.
1. No command runs a scenario
bernstein scenario and bernstein scenarios are not registered in src/bernstein/cli/main.py. The only scenario surface is bernstein routine scenarios (deprecated) and bernstein schedule routine scenarios, and both only list the library.
2. Emitted tasks are code-shaped whatever the deliverable is
ScenarioTaskTemplate in src/bernstein/core/planning/scenario_library.py carries exactly title, description, role, priority, scope, complexity. There is no artifact_spec anywhere in that module, and src/bernstein/core/tasks/models.py defaults artifact_spec to code_diff. A scenario describing a research deliverable therefore emits tasks that can only complete by producing a diff.
3. The library has two roots and they do not meet
src/bernstein/core/planning/roadmap_runtime.py reads workdir/.bernstein/scenarios — the operator's own scenarios.src/bernstein/cli/commands/routine_cmd.py defaults to the packaged templates/scenarios — the shipped library.
So a scenario the operator writes is invisible to the listing command, and a shipped scenario is invisible to the runtime. Neither directory is wrong; nothing layers them.
The decision, so it is not re-argued: the workspace directory is the operator's surface and wins on name collision; the packaged directory is the read-only default set. Every reader resolves the workspace root first and falls back to the packaged one, and the listing says which root each entry came from.
Not a regression of #5573
#5573 asked for reachability or a visible outcome, and said plainly that silence was the only unacceptable result. The diagnostic that landed for it reports reason="no-roadmap" with scenarios_found and emitted, which is what it asked for. It is correctly closed. This issue is the next step, not a reopen.
What must become true
- A single documented command takes a scenario from the workspace library and runs it to completion, from a workspace a fresh
bernstein init produces.
artifact_spec is carried from the scenario definition through emission onto the task, so a non-code deliverable completes on its own artifact rather than a diff. An unspecified one keeps today's default.- Both the runtime and the listing resolve the workspace root first and the packaged root second, and the listing names the root per entry.
Checked by
A test that runs a scenario whose task declares a non-code artifact_spec in a workspace built by bernstein init, and asserts the emitted task carries that spec rather than code_diff. Plus one test that a workspace entry shadows a packaged entry of the same name, and one that the listing reports the root.
Blocks
#4910, which cannot be written honestly until a reader following it from a fresh install gets real output.
A workspace scenario cannot be run end to end from the CLI, and a task a scenario emits cannot complete on anything but a code diff. Both are needed before the quickstart in #4910 can be written against real command output.
All three findings below were checked against
mainat453f8de.1. No command runs a scenario
bernstein scenarioandbernstein scenariosare not registered insrc/bernstein/cli/main.py. The only scenario surface isbernstein routine scenarios(deprecated) andbernstein schedule routine scenarios, and both only list the library.2. Emitted tasks are code-shaped whatever the deliverable is
ScenarioTaskTemplateinsrc/bernstein/core/planning/scenario_library.pycarries exactlytitle,description,role,priority,scope,complexity. There is noartifact_specanywhere in that module, andsrc/bernstein/core/tasks/models.pydefaultsartifact_spectocode_diff. A scenario describing a research deliverable therefore emits tasks that can only complete by producing a diff.3. The library has two roots and they do not meet
src/bernstein/core/planning/roadmap_runtime.pyreadsworkdir/.bernstein/scenarios— the operator's own scenarios.src/bernstein/cli/commands/routine_cmd.pydefaults to the packagedtemplates/scenarios— the shipped library.So a scenario the operator writes is invisible to the listing command, and a shipped scenario is invisible to the runtime. Neither directory is wrong; nothing layers them.
The decision, so it is not re-argued: the workspace directory is the operator's surface and wins on name collision; the packaged directory is the read-only default set. Every reader resolves the workspace root first and falls back to the packaged one, and the listing says which root each entry came from.
Not a regression of #5573
#5573 asked for reachability or a visible outcome, and said plainly that silence was the only unacceptable result. The diagnostic that landed for it reports
reason="no-roadmap"withscenarios_foundandemitted, which is what it asked for. It is correctly closed. This issue is the next step, not a reopen.What must become true
bernstein initproduces.artifact_specis carried from the scenario definition through emission onto the task, so a non-code deliverable completes on its own artifact rather than a diff. An unspecified one keeps today's default.Checked by
A test that runs a scenario whose task declares a non-code
artifact_specin a workspace built bybernstein init, and asserts the emitted task carries that spec rather thancode_diff. Plus one test that a workspace entry shadows a packaged entry of the same name, and one that the listing reports the root.Blocks
#4910, which cannot be written honestly until a reader following it from a fresh install gets real output.