Commit graph

2 commits

Author SHA1 Message Date
e33d6bb1ad feat: record install-time state, show CircuitForge node info in quickinfo
- lib/cf-apps.functions: cf-provision-node/install-cf-app/
  provision-orchard-node now write to ~/.config/cf-node-bootstrap/state.conf
  (record-cf-node-state) - provisioning profile, each installed app
  (name:install_type:clone_dir), and orchard role/coordinator URL. The
  orchard role/coordinator is read back from circuitforge-orch's own
  generated ~/.config/circuitforge/cf-orch.env rather than tracked
  separately, since that's the actual source of truth for what its
  interactive installer decided.
- 11-quickinfo.bashrc: new "CircuitForge Node" section (show_cf_node_info,
  default true) displaying the provisioning profile, orchard role/
  coordinator if joined, and each installed app with a best-effort
  running/stopped status. Docker-compose apps are checked by compose
  project from their clone dir rather than by container name, since
  compose's generated container names don't match the app name directly.
  Section is entirely absent if the state file doesn't exist yet (i.e.
  the CF Apps menu has never been run on this node).
2026-07-17 21:16:07 -07:00
2a325b55bd feat: interactive CF Apps install menu with oem/collaborator/orchard profiles
Adds a manifest-driven "Install CircuitForge Apps" menu to install.sh,
alongside the existing extras-menu pattern.

- cf-apps/*.manifest: one file per product (circuitforge-core, peregrine,
  kiwi, snipe, turnstone, pagepiper, linnet - the beta/alpha menagerie
  products), declaring repo URLs, supported install types, conda env,
  .env template, and per-install-type setup hooks. Hooks prefer shelling
  out to each product's own install.sh/Makefile/docker-compose rather
  than reimplementing their setup logic.
- lib/cf-apps.functions: registry loader, provisioning-profile prompt
  (oem/collaborator/orchard), app multiselect menu, and the install
  dispatcher (clone, .env bootstrap, install-type selection, hook
  dispatch). circuitforge-core installs automatically as a dependency
  for apps that declare app_needs_core=true.

Provisioning profiles gate both which apps are offered and which remote
credentials are used:
- oem: public CircuitForgeLLC GitHub mirrors only, no Forgejo access,
  no circuitforge-orch (product install menu only)
- collaborator: private Circuit-Forge Forgejo, same product menu
- orchard: narrow flow, not the product menu - clones circuitforge-orch
  (Forgejo-only, no public mirror exists) and hands off interactively to
  its own install.sh, which gathers agent/coordinator topology itself
  (it has no --topology/--coordinator-url flags to script around).
  NOTE: circuitforge-orch has no model-sync/cache-sync mechanism today
  (checked its install.sh and README); this wrapper doesn't invent one.

Design rationale and survey of each product's real install story:
circuitforge-plans/cf-node-bootstrap/superpowers/plans/2026-07-17-cf-apps-install-menu.md
2026-07-17 20:42:21 -07:00