How Stackiln works
The generation model, ownership rules, and safety boundaries.
Build-time, not runtime
Stackiln copies a deployable base and selected module source into a new workspace. Production code does not import Stackiln. The generated product owns its source, lockfile, database migrations, tests, and deployment files.
This keeps deployment conventional. You can continue without Stackiln, replace generated pieces, or move the repository to a different host.
Plan, stage, commit
Planning resolves the preset, optional modules, dependencies, files, routes, tables, environment variables, and package dependencies without writing the destination.
Creation writes to a sibling staging directory. Stackiln validates that staged product and renames it into place only after the operation succeeds. A failed operation removes only its own staging directory.
Explicit ownership
Every module declares the surfaces it owns. The planner rejects undeclared copied files, dependency cycles, file collisions, route collisions, table collisions, environment-name collisions, and incompatible modules before generation.
Ownership describes provenance; it does not prevent product developers from editing generated code.
Product changes are protected
The .stackiln/state.json file records SHA-256 checksums for managed files. Doctor compares the current workspace with that state so future tooling can distinguish unchanged generated code from product customisations.
Automatic upgrade proposals are not implemented yet. Never copy a newer template over a customised product without reviewing the difference.