Handbook

Dual-wiki architecture

Forge STI uses the private handbook pair pattern shared by Fleet, LCDL, Lenses, and Platform: product Markdown in sti, Firebase deploy wiring in stiw.

Updated

Repo Abbr Owns Does not own
forge-sti sti docs/, schemas/, src/forge_sti/, Cursor composer prompts Firebase config, generator, Hosting chrome
forge-sti-website stiw generator/, firebase.json, website/ HTML, kitchensink submodule Product spec source of truth

Publish loop

  1. Edit and commit in forge-sti (this repo).
  2. In forge-sti-website, bump the forge-sti submodule to that commit.
  3. Run python3 generator/build-site.py from stiw.
  4. Deploy: ./deploy-websites.sh --only forge-sti-website from the Code workspace root.

Canonical URL (when Hosting is provisioned): https://sti.forgesdlc.com (Firebase project forge-sti-handbook).

Decision rules

  1. Product documentation or schema change → edit sti only.
  2. Generator, Firebase, or nav chrome change → edit stiw only.
  3. Kitchen Sink CSS/components changed → propagate KS first (sync-kitchensink-and-rebuild.sh), then rebuild stiw.
  4. One commit per repo — never stage sti and stiw together.

Submodule safety

When mirroring sti into the stiw submodule without waiting on remote SHA, never delete the submodule .git/ directory. Prefer git submodule update --remote forge-sti after push, or scoped rsync into docs/ and schemas/ only.

What is not dual-wiki here

Capablio-style wiki/external + wiki/internal split is out of scope. STI dual-wiki means product repo ↔ handbook deploy shell only.

  • Website publishing
  • Workspace bridge: handbook-deploy-pairs (sti + stiw listed after catalog sync)