- Publish job was overriding runner env with empty string via secrets ref
- Build job could fail on dirty workdir from previous failed run
- Runner env already provides GITEA_NPM_TOKEN — no secrets store needed
- Phase 2: install act_runner binary, register with Gitea, create systemd service
- Phase 3: push all 11 repos to VM Gitea after cloning from GitHub
- Expanded Gitea API token scopes (write:repository, write:user)
- Runner config: host mode, capacity 2, GITEA_NPM_TOKEN injected
- Enables CI on the VM for NETWORK!=corp usage
- Add publish-packages job to CI workflow (runs after build-and-test)
- Publish 13 remaining packages to Gitea (56 total, up from 43)
- Update act_runner token to read+write scope
- Fix package counts throughout migration doc (43 → 56)
- Update CI status: all 10/10 repos now have CI workflows
- Add package inventory section (§15.1)
- Created .npmrc with @bytelyst scoped registry pointing to local Gitea
- Added publishConfig.registry to all 57 @bytelyst/* package.json files
- Created scripts/harden-publish-config.sh for future re-runs
- Prevents accidental publish to npmjs.org or corporate JFrog registry
- NETWORK=corp → GITEA_NPM_HOST=localhost (local Gitea Docker)
- NETWORK=home → GITEA_NPM_HOST from ~/.gitea_vm_host (Azure VM)
- Fallback: localhost if ~/.gitea_vm_host doesn't exist
This enables all repo .npmrc files to use ${GITEA_NPM_HOST}:3300
instead of hardcoded localhost:3300, matching the existing
.npmrc.docker pattern used during Docker builds.
- Add NO_PROXY/no_proxy/NPM_CONFIG_NOPROXY=localhost,127.0.0.1 when
NETWORK=corp so local services (Gitea npm registry, Cosmos emulator,
Azurite) bypass the corporate proxy. Previously NO_PROXY was only set
in .zshrc line 5, making the script not self-contained.
- Add GITEA_NPM_TOKEN auto-load from ~/.gitea_npm_token file
(regardless of NETWORK). Reads are public, but publish needs the
token. This ensures local pnpm install resolves @bytelyst/* auth.
- Unset NO_PROXY/no_proxy/NPM_CONFIG_NOPROXY when NETWORK=home.
- Phase 3 now exits with error if any image builds fail, preventing
mark_phase_done from running. Previously it just warned and continued,
which could lead to phase 5 deploying with missing images.
- Moved mkdir from top-level scope into mark_phase_done(). The old
top-level mkdir -p /opt/bytelyst/.setup-state-k8s crashed non-root
invocations (--status, --help) due to set -e + permission denied.
- Fixed header comment: 'containerd' → 'Docker runtime' (we use --docker).
- Added --resume to header usage block (was supported but undocumented).
YAML anchors (&name/*name) are scoped per document. In multi-document
files (separated by ---), anchors defined in one document cannot be
referenced from another. This caused all backends/webs after the first
to fail kubectl apply with unknown alias errors.
Fixed by inlining envFrom, resources, and labels in every Deployment.
- Added 15 recent fixes to the Bugs Already Fixed table
- Fixed line count (~940 → ~990)
- Fixed stale lysnrai-web → lysnrai-dashboard in architecture diagram
- Fixed test plan service count (27+ → 30+)
- Updated constraint: compose/Dockerfile changes allowed with verification
Each product web app reads different env var names in product-config.ts.
The compose file was using generic NEXT_PUBLIC_BACKEND_URL and
NEXT_PUBLIC_PLATFORM_URL for all 9 web services, but most products
use different names. This caused SSR (server-side rendering) to miss
the correct backend/platform URLs.
Corrected per product:
- lysnrai-dashboard: PLATFORM_SERVICE_URL (server-side, not NEXT_PUBLIC)
- chronomind-web: NEXT_PUBLIC_BACKEND_URL + NEXT_PUBLIC_PLATFORM_SERVICE_URL
- jarvisjr-web: NEXT_PUBLIC_PLATFORM_SERVICE_URL (no backend client)
- flowmonk-web: NEXT_PUBLIC_PLATFORM_URL (backend is hardcoded)
- notelett-web: NEXT_PUBLIC_NOTES_API_URL + NEXT_PUBLIC_PLATFORM_SERVICE_URL
- mindlyst-web: NEXT_PUBLIC_PLATFORM_SERVICE_URL
- nomgap-web: NEXT_PUBLIC_NOMGAP_API_URL + NEXT_PUBLIC_PLATFORM_SERVICE_URL
- actiontrail-web: NEXT_PUBLIC_API_URL + NEXT_PUBLIC_PLATFORM_URL
- localmemgpt-web: already correct (unchanged)
ollama pull piped through tail with set -euo pipefail would abort the
entire 8-phase setup on a slow network or wrong model name. Only
LocalMemGPT needs the model — the other 9 products are unaffected.
1. last_completed_phase now stops at first gap — prevents --resume from
skipping phases when --phase=N created non-sequential markers
2. Phase 7 fails early if .env.ecosystem is missing (points to --phase=6)
3. Warns if compose config JSON cache fails — graceful degradation
1. set -e + pipefail: docker compose up piped through tail would abort
script on partial startup failure before printing summary — add || true
2. Phase 7 marked done even with build failures, so --resume would skip
it — now only marks done when all builds succeed
3. --phase=7 printed 'Phase 7 complete' even with failures — now exits
with code 1 and points to build logs
4. docker compose config --format json called 30 times in build loop —
now cached once (saves ~3s)
5. Build logs now saved per-service to STATE_DIR/builds/<svc>.log for
post-failure debugging
- --resume: auto-detect last completed phase and continue from there
- --resume-from=N: resume from a specific phase
- --phase=N: run only one phase (e.g. --phase=7 to retry deploy)
- --reset: clear phase markers and start fresh
- --status: show completed phases
- Phase 7 now builds each of 27 services individually with progress
- Failed builds are skipped; remaining services still start
- Phase completion markers stored in /opt/bytelyst/.setup-state/
- GITEA_NPM_TOKEN auto-restored from saved state on resume
