These were already wrong before any deletion. module-builder repointed the
cdylib Qt glue onto logos-plugin-qt's logos-qt-host-generator (5081088) and the
docs kept naming logos-qt-generator, so the pipeline they describe has not been
the pipeline that runs for some time.
That matters more here than in most docs: guidelines/ and docs/ are SHIPPED —
flake.nix copies them into the dev-boost output, and generate-agents-md.ts
embeds them into every scaffolded module's AGENTS.md/CLAUDE.md. So the stale
line was being handed to module authors, and to agents reading the scaffold, as
the instruction. That is why the six doctests/outputs/ files change too: they
are the recorded scaffolder output, and they carry the same text.
Only the middle step moves. `logos-cpp-generator --backend cdylib` — the Qt-free
C-ABI export wrapper — is a different tool doing a different job and is
deliberately untouched; it remains correct in every one of these blocks.
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Universal modules build as header-first cdylibs now, but the docs still
described the old `logos-cpp-generator --from-header --backend qt` path that
emitted `<name>_qt_glue.h` + `<name>_dispatch.cpp` and listed them explicitly
in CMakeLists SOURCES. None of that is current:
- The generator derives a `.lidl` from the impl header, then runs the cdylib
backend → `<name>_cdylib_glue.{h,cpp}` (uniform Qt-plugin glue) +
`<name>_module_impl.cpp` (Qt-free C-ABI export wrapper).
- `mkLogosModule` runs the pipeline automatically — no `preConfigure`.
- `LogosModule.cmake` globs `generated_code/` — modules must NOT list the
generated files in SOURCES (the bug fixed in #12).
Updated across the board:
- guidelines/{codegen.md (rewritten),universal-module,nix-build,metadata-json}
- docs/{spec.md,project.md}, README.md
- skills/{create-universal-module,nix-flake-setup,wrap-external-lib}
- generators/generate-agents-md.ts, mcp-server/tools/build-help.ts
(build-help now flags the "generated_code in SOURCES" mistake directly)
- regenerated llms-full.txt + llms.txt
- refreshed the committed example trees (outputs/logos-*) to match current
`init` output: minimal flake (no preConfigure), CMakeLists without the
generated_code sources, and regenerated AGENTS.md/CLAUDE.md/.claude skills
- re-rendered dev-boost-scaffold-module.md
No source-code/behavior changes — docs + generated context only.
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The scaffolded module flake.nix hard-coded a preConfigure calling
`logos-cpp-generator --from-header ... --backend qt`. The logos-qt-sdk
split moved Qt-plugin glue generation to `logos-qt-generator`, and
logos-cpp-generator now hard-errors on `--backend qt` ("Qt glue generation
moved to logos-qt-generator"). So every scaffolded universal module (and
the module half of `full-app`) failed to build against a post-split
cpp-sdk — masked until now only by Cachix hits on pre-split builds.
Drop the hand-written preConfigure entirely. logos-module-builder's
mkLogosModule already runs the generator automatically for
`interface: "universal"` modules (via logos-qt-generator + the .lidl
sidecar), and the scaffold's conventional <Pascal>Impl / <name>_impl.h
naming matches the builder's defaults — so no preConfigure or codegen
metadata is needed. Verified: `init --type module` then `nix build`
produces the plugin via the autoCodegen path.
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
