Finding
A default typikon-init run adds the theme submodule from the loopback forge URL, so Git records http://127.0.0.1:7878/forkwright/typikon.git in the new consumer's .gitmodules. The same scaffold generates a GitHub Actions workflow that recursively checks out submodules, where that URL necessarily points at the hosted runner rather than the operator's forge. The declared GitHub theme URL is never used.
Evidence
bin/typikon-init:35-36 defines both forge and GitHub theme URLs.bin/typikon-init:78-81 runs git submodule add "$THEME_REPO", which makes the loopback forge URL the portable repository metadata.ci/github-workflow.yml.tmpl:30-32 asks GitHub's checkout action to fetch submodules recursively.THEME_REPO_GH has no productive use in the script.- The first consumer encountered the exact failure: ardent-site commit
bf66294 records that GitHub Actions could not reach the forge and changes .gitmodules to the public GitHub mirror. It documents the durable local override pattern separately.
Issues #25, #27, and #29 cover stale bootstrap documentation, generated lint violations, and deployed-vs-local browser gates; none covers submodule reachability.
Why this matters
Every freshly generated consumer contains a CI workflow that cannot complete its first checkout. The scaffolder creates contradictory fleet state and pushes a known repair onto every consumer, undermining both idempotent setup and the purpose of owning a substrate.
Desired correction
Store a universally readable, non-loopback mirror URL in .gitmodules—normally the public GitHub HTTPS URL—and configure operator-local clones to override submodule.themes/typikon.url to the forge. Derive both URLs from one typed scaffold configuration, and add a generated-consumer acceptance test that creates a fresh site and proves a clean, network-isolated CI-style clone can initialize the theme without operator state.
Finding
A default
typikon-initrun adds the theme submodule from the loopback forge URL, so Git recordshttp://127.0.0.1:7878/forkwright/typikon.gitin the new consumer's.gitmodules. The same scaffold generates a GitHub Actions workflow that recursively checks out submodules, where that URL necessarily points at the hosted runner rather than the operator's forge. The declared GitHub theme URL is never used.Evidence
bin/typikon-init:35-36defines both forge and GitHub theme URLs.bin/typikon-init:78-81runsgit submodule add "$THEME_REPO", which makes the loopback forge URL the portable repository metadata.ci/github-workflow.yml.tmpl:30-32asks GitHub's checkout action to fetch submodules recursively.THEME_REPO_GHhas no productive use in the script.bf66294records that GitHub Actions could not reach the forge and changes.gitmodulesto the public GitHub mirror. It documents the durable local override pattern separately.Issues #25, #27, and #29 cover stale bootstrap documentation, generated lint violations, and deployed-vs-local browser gates; none covers submodule reachability.
Why this matters
Every freshly generated consumer contains a CI workflow that cannot complete its first checkout. The scaffolder creates contradictory fleet state and pushes a known repair onto every consumer, undermining both idempotent setup and the purpose of owning a substrate.
Desired correction
Store a universally readable, non-loopback mirror URL in
.gitmodules—normally the public GitHub HTTPS URL—and configure operator-local clones to overridesubmodule.themes/typikon.urlto the forge. Derive both URLs from one typed scaffold configuration, and add a generated-consumer acceptance test that creates a fresh site and proves a clean, network-isolated CI-style clone can initialize the theme without operator state.