refactor: rename internal Fai* design system + fai_ helpers to chain
Some checks failed
Security / Security check (push) Failing after 2s

The Studio design system, widgets and helpers carried a Fai* / fai_
prefix (FaiSpace, FaiColors, FaiTheme, FaiLog, 17 fai_*.dart files, the
faiBinary* l10n keys). Studio is the Ch∆In product, so rename them to
Chain* / chain_ — carefully preserving English fail/failure/failed.
Also fix stale references: the 'fai' binary in l10n strings -> 'chain',
FAI_* env vars (FAI_BIN/DATA_DIR/MODULES_DIR/TODAY/BOOTSTRAP_TOKEN) ->
CHAIN_*, fai_platform -> fai_chain, fai_hub -> chain_hub. Vendor
security-hook tooling (FAI_BANNED_TERMS_FILE) + the .fai bundle ext left.
flutter analyze + test: clean (20 passed).

Signed-off-by: flemming-it <stefan.a.flemming@googlemail.com>
This commit is contained in:
flemming-it 2026-06-16 17:53:17 +02:00
parent 68d23ab7dd
commit 891acd2ba2
52 changed files with 1225 additions and 1225 deletions

View file

@ -35,14 +35,14 @@ flutter test test/integration/
```
Prereq: a `fai` binary on PATH or at
`../fai_platform/target/release/fai`. The harness skips with a
`../fai_chain/target/release/chain`. The harness skips with a
clear message when neither exists, so this command does not
fail on a fresh checkout — it just reports skipped tests.
To get the binary:
```bash
cd ../fai_platform
cd ../fai_chain
cargo build --release --bin fai
```
@ -52,11 +52,11 @@ A cold `chain serve` spends its first ~30s building the
curated-model database and initialising SQLite migrations.
`HubFixture.start()` waits up to 60s by default; if your local
hub takes longer the first time, run `chain serve` once by hand
against any temp `FAI_DATA_DIR` to warm the per-user cargo /
against any temp `CHAIN_DATA_DIR` to warm the per-user cargo /
SBOM caches:
```bash
FAI_DATA_DIR=/tmp/fai_warmup chain serve --bind 127.0.0.1:0
CHAIN_DATA_DIR=/tmp/chain_warmup chain serve --bind 127.0.0.1:0
# wait for "hub started", Ctrl-C
```
@ -66,7 +66,7 @@ Subsequent integration-test runs are quick.
`.forgejo/workflows/ci.yml` doesn't run these yet. Adding them
needs an artifact-passing pattern: the platform build job
publishes `target/release/fai` as a CI artifact; the studio
publishes `target/release/chain` as a CI artifact; the studio
test job consumes it. Pattern is straightforward once we want
it; it's deferred because we don't yet have enough integration
tests to justify the CI runtime.