You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The closed-issue audit of #103 found two items from the issue text that its staged plan (#151 → #190 → #212 → #225 → #239/#244) never delivered and that no other issue carries:
Script proof in the consumer harness.Generate an Agent Bundle framework test harness on top of Rstest #103's proposed public surface lists runScript beside renderRoute / invokeMcpTool / invokeCli, and test level 2 ("projection contract harness") says it "executes plain and rendered scripts". On origin/main (af1c18551) agent-bundle/test exports eight proof levels (route-unit, mcp-in-memory, cli-dispatch, packed-stdio, packed-deleted-source, browser-app, simulated, host-install) and none of them runs a conventional src/scripts/*.{ts,tsx} module. Script output modes are proven only inside the repository (packages/agent-bundle/tests/cli-routes-build.test.ts, Generate CLI, MCPorter, and script projections from the compiled route graph #102 stage 4), so a consumer cannot assert a rendered script's --json / --ndjson / piped-Markdown output without reconstructing the generated executable.
runScript(name, argv, options) at a new honestly labeled proof level (in-process dispatch through the same render-session contract the generated scripts/<name>.mjs executable uses, mirroring how invokeCli reuses runGeneratedCliEntry): plain .ts scripts execute with ordinary stdout/stderr capture; rendered .tsx scripts expose cliJson / cliNdjson-style accessors plus piped Markdown.
The test manifest carries script descriptors from the same compiler pass (AgentBundleTestManifest.scripts), collision-checked like cliCommands.
Provenance stamps the level and prints it in every failure; a pass here is not packed or host evidence.
Adoption: one rendered-script test in examples/audiobook-curator or the route-harness fixture; packages/agent-bundle/README.md proof-level table row.
Why this exists
The closed-issue audit of #103 found two items from the issue text that its staged plan (#151 → #190 → #212 → #225 → #239/#244) never delivered and that no other issue carries:
runScriptbesiderenderRoute/invokeMcpTool/invokeCli, and test level 2 ("projection contract harness") says it "executes plain and rendered scripts". Onorigin/main(af1c18551)agent-bundle/testexports eight proof levels (route-unit,mcp-in-memory,cli-dispatch,packed-stdio,packed-deleted-source,browser-app,simulated,host-install) and none of them runs a conventionalsrc/scripts/*.{ts,tsx}module. Script output modes are proven only inside the repository (packages/agent-bundle/tests/cli-routes-build.test.ts, Generate CLI, MCPorter, and script projections from the compiled route graph #102 stage 4), so a consumer cannot assert a rendered script's--json/--ndjson/ piped-Markdown output without reconstructing the generated executable.agent-bundle/test/browser. If this is intentionally not a consumer surface (the Workbench is the framework's own dev tool, not a route the consumer authors), record that decision here and close; otherwise it needs an owner.Scope (item 1)
runScript(name, argv, options)at a new honestly labeled proof level (in-process dispatch through the same render-session contract the generatedscripts/<name>.mjsexecutable uses, mirroring howinvokeClireusesrunGeneratedCliEntry): plain.tsscripts execute with ordinary stdout/stderr capture; rendered.tsxscripts exposecliJson/cliNdjson-style accessors plus piped Markdown.AgentBundleTestManifest.scripts), collision-checked likecliCommands.examples/audiobook-curatoror theroute-harnessfixture;packages/agent-bundle/README.mdproof-level table row.Refs: #103 (proposed surface + level 2), #102 stage 4 (#278), #105.