What Loom Generates

loom weave produces ten files per Thread. They land under .loom/ so they're easy to clean up (rm -rf .loom) and trivially excluded from version control.

Layout

For a Thread named Customer, weaving produces:

.loom/
├── sql/
│   └── customers.sql                                    CREATE TABLE migration
├── go/
│   ├── models/
│   │   └── customer.go                                  struct + db/json/validate tags
│   ├── handlers/
│   │   ├── customer.go                                  List/Get/Create/Update/Delete
│   │   └── customer_test.go                             auth-required smoke test
│   └── routes/
│       └── customer.go                                  chi route mount function
├── svelte/src/routes/customers/
│   ├── +page.svelte                                     list view
│   ├── new/+page.svelte                                 create form
│   └── [id]/+page.svelte                                detail view
└── htmx/
    ├── customers_list.html                              HTMX-driven list partial
    └── customers_form.html                              HTMX-driven form partial

Should I commit .loom/?

Generally no. Treat it like any build artefact:

• It's reproducible from loom weave against the same Thread definitions.
• It's gofmt-stable (Loom runs go/format on the Go output before writing), so re-runs are byte-identical.
• Committing it adds noise to PRs whenever a Thread changes.

The framework's own .gitignore excludes .loom/sql/, .loom/go/, .loom/svelte/, .loom/htmx/. Use the same pattern in your project.

When does the generated code run?

loom serve does not consume .loom/go/. It uses interpreter mode — generic CRUD handlers driven directly by your Thread definitions at runtime. The generated Go is reference code for users who want to customise.

To take ownership of generated handlers, run loom eject <Model>. That moves the four Go files for that model to custom/, strips the "Generated by Loom" header, and leaves you free to edit. From that point you maintain a custom main.go that wires the ejected code through chi.

SQL is the exception

.loom/sql/*.sql is consumed by loom stitch for the initial table creation. After the first stitch, future schema changes are emitted as ALTER TABLE statements derived from the diff between Thread definitions and information_schema. The generated CREATE TABLE files remain useful as documentation and for fresh-database bootstraps.