Gap (observed in live gameplay): the agent cannot interact with DFHack''s built-in quickfort blueprint library — dreamfort, the aquifer taps, the pump stacks, bedroom blocks, etc. blueprint_apply only accepts an inline CSV drafted by the agent (src/tools/blueprint.ts), so the entire curated library that ships with DFHack (hack/data/blueprints/library/) is invisible and unusable. Given the whole project rides on DFHack, that''s a real affordance gap — the library is exactly the high-quality, play-tested content an AI co-pilot should be able to surface and execute on request.
Proposed shape (facts-only doctrine preserved):
blueprint_library() sensor — list available blueprints (shipped library + the user''s own blueprints/ dir) with their metadata: name, path, modes present (#dig/#build/#place/#query/#meta), labels/phases (dreamfort is multi-sheet, phase-driven), z-level span, comment/help text. Backing: quickfort list --library and quickfort''s own parsing internals (hack/scripts/internal/quickfort/*.lua); the data is all on disk + parseable via reqscript.- Extend
blueprint_apply to accept a library reference (path + sheet/label) as an alternative to inline csv, running the same dry-run/confirm/apply loop (quickfort run <path> -n <label> --dry-run for the preview).
- Prerequisite / staging: v1 deliberately rejects
#build/#place modes (nothing partially applies). Library dig-phase blueprints (e.g. dreamfort''s /dig_all) work under today''s scope; full dreamfort needs the build/place mode expansion, which this issue should stage as a follow-up rather than block on.
Undo caveat: quickfort''s native undo applies per-blueprint-run, same as today''s inline flow, but multi-phase library runs need the sensor to report phases so the agent applies (and can undo) one phase at a time.
From live-gameplay feedback + the post-v1.0 gap analysis.
Gap (observed in live gameplay): the agent cannot interact with DFHack''s built-in quickfort blueprint library — dreamfort, the aquifer taps, the pump stacks, bedroom blocks, etc.
blueprint_applyonly accepts an inline CSV drafted by the agent (src/tools/blueprint.ts), so the entire curated library that ships with DFHack (hack/data/blueprints/library/) is invisible and unusable. Given the whole project rides on DFHack, that''s a real affordance gap — the library is exactly the high-quality, play-tested content an AI co-pilot should be able to surface and execute on request.Proposed shape (facts-only doctrine preserved):
blueprint_library()sensor — list available blueprints (shipped library + the user''s ownblueprints/dir) with their metadata: name, path, modes present (#dig/#build/#place/#query/#meta), labels/phases (dreamfort is multi-sheet, phase-driven), z-level span, comment/help text. Backing:quickfort list --libraryand quickfort''s own parsing internals (hack/scripts/internal/quickfort/*.lua); the data is all on disk + parseable via reqscript.blueprint_applyto accept a library reference (path + sheet/label) as an alternative to inlinecsv, running the same dry-run/confirm/apply loop (quickfort run <path> -n <label> --dry-runfor the preview).#build/#placemodes (nothing partially applies). Library dig-phase blueprints (e.g. dreamfort''s/dig_all) work under today''s scope; full dreamfort needs the build/place mode expansion, which this issue should stage as a follow-up rather than block on.Undo caveat: quickfort''s native undo applies per-blueprint-run, same as today''s inline flow, but multi-phase library runs need the sensor to report phases so the agent applies (and can undo) one phase at a time.
From live-gameplay feedback + the post-v1.0 gap analysis.