A bin claim on a src/scripts module silently removes it from conventional script discovery (artifact scripts/ ends up empty)

[ScriptedAlchemy]

What happened

agent-bundle.config.ts:

bin: { hauler: './src/scripts/hauler.ts' },

src/scripts/hauler.ts is a conventional script route (the hooks rewrite target scripts/hauler.mjs). Because configClaimedSources() treats a bin entry as a claim, the module is filtered out of route discovery entirely: inspect --json shows model.packageBuild.bins containing hauler but model.scripts: [], and the host artifact has no scripts/hauler.mjs. No diagnostic is emitted — the file just stops shipping.

The fix was to also declare it explicitly:

scripts: { hauler: './src/scripts/hauler.ts' },
bin:     { hauler: './src/scripts/hauler.ts' },

Ask

Either keep bin-claimed src/scripts/* modules in script discovery (a bin and an artifact script are not mutually exclusive — this is exactly the "same entry, npm bin + hook target" case), or emit a diagnostic when a conventional src/scripts module is claimed by bin alone so the disappearance is visible.

Also observed: simulateHook() from agent-bundle/api takes ~7 s per call on this machine (each call appears to re-prepare the project); the generated wrappers themselves answer in ~0.5 s. Three simulate calls blow a default 30 s test timeout. Caching the prepared project across calls in one process would help consumer test suites.

Pin: agent-bundle@105c65d8f.

[ScriptedAlchemy]

Fixed in #413 (squash-merged as 1c82c31d4).

What changed

• A bin entry that references a conventional src/scripts/<name>.ts module no longer removes it from script discovery. configClaimedSources() now reports bin claims separately from scripts/hooks/lib/mcp claims, and a bin claim on a safely named direct src/scripts/<name> child keeps the module a conventional script. The same entry therefore ships as both dist/bin/<name>.js and <target>/scripts/<name>.mjs, and inspect --json lists it under both model.packageBuild.bins and model.scripts. The scripts: { hauler: ... } + bin: { hauler: ... } workaround is no longer needed (it still works).
• An explicit scripts: claim still takes precedence over the convention (AB4808/AB4809 unchanged); hooks, lib, and mcp entries still claim the module they reference; nested or unsafely named src/scripts/** modules named by bin stay claimed so a bin-only config never regresses into AB4808/AB4803.
• Never silent: two new errors, documented in docs/diagnostics.md. AB4737 — a bin entry points at a rendered src/scripts/<name>.tsx that does not export both an async default Server Component and a named main (the bin envelope calls main, the script renders the component). AB4738 — a bin entry points at a plain src/scripts/<name>.ts that exports a default but no main (the bin would run the default while the artifact script shipped inert). main-exporting and self-executing modules ship on both surfaces with no diagnostic.
• Docs: docs/entry-conventions.md gains a "Which config keys claim a conventional module" precedence table; packages/agent-bundle/README.md states the rule. Changeset: minor (a previously bin-only default-export module now needs main or a _ prefix).

Tests

• tests/route-graph.test.ts: bin-claimed direct child stays discovered; nested / spaced-stem bin entries and lib.entry stay claimed; AB4737 (component-only, main-only, non-callable default, type-only default alias) vs. accepted (main + component, main + re-exported default); AB4738 (default-only) vs. accepted (main, self-executing).
• tests/normalization.test.ts: AB4737 message/recovery and dual-surface model shape.
• tests/package-build.test.ts: real build with bin: { hauler: './src/scripts/hauler.ts' } — no diagnostics, both model surfaces, dist/bin/hauler.js and artifact/portable/scripts/hauler.mjs both exist and execute.

Not addressed here: simulateHook() ~7 s per call. Each call runs temporaryArtifact(), i.e. a full build() into a temp directory that is removed afterwards — the cost is the build, not a "prepare" step. A per-process memo keyed on root + config mtime would have to keep the temp artifact alive across calls and would go stale on any source edit, so it is not a safe api-layer cache. SimulateHookOptions.artifact already lets a consumer build() once and run many simulateHook({ artifact, ... }) calls against it in ~0.5 s each; that is the recommended shape for consumer test suites.