It was in both light profiles on the reasoning that it fronts a REMOTE instance and so needs nothing installed locally. That is true and it was beside the point: a baseline process appears in the dock and in the Permissions screen whether or not anyone ever gave it a URL, so a fresh server offered to grant members access to a Gitea that did not exist. "Is Gitea here" had two answers that could disagree. Now it is `existing` mode with a URL and a token, like any other remote service, and the one place that says whether it is here is the install row. No compose template and no `provisioned` mode: Gitea is always something the owner already runs, and offering to spin one up would mean owning its migration, backup and upgrade story. members: 'none' — not because Gitea is single-tenant, it is the most per-user service in the catalogue, but because there is nothing for the INSTALLER to do. The owner's connection carries the instance; each member adds their own access token from /gitea and acts only as themselves upstream. A provisioner would need an admin token and would mint credentials on their behalf, which is more authority than this needs. The catalogue test already pinned "the store offers exactly what light leaves out", so removing it from the profile is what forced the entry to exist. Both light profiles changed together — the mac one carried the same comment and the same gap. Permissions on a fresh install is now Files and Plans. Plans stays because it reads the platform's own shipped markdown from <repo>/plans, not anyone's disk, so it needs nothing installed and exposes nothing. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
69 lines
3.9 KiB
JavaScript
69 lines
3.9 KiB
JavaScript
// macOS light profile — the same process set as the Linux light profile, on a laptop.
|
|
//
|
|
// Paired with scripts/setup_mac_light.sh. Runs the file browser, the terminal and Claude/opencode
|
|
// chat; nothing else.
|
|
//
|
|
// This is a subset of ecosystem.config.cjs, not a copy of it. That distinction is here because of this
|
|
// file specifically: written on 2026-07-28 as a hand-copied process list, it was broken within days by
|
|
// two changes it could not see. It ran `officer-claude` against the Anthropic proxy's entry point
|
|
// while the process that actually spawns `claude` was never started, and it pointed at a pty sidecar
|
|
// that had moved. Both failures were silent — the processes simply did not come up. See
|
|
// ecosystem.profile.cjs for the checks that now make that loud.
|
|
//
|
|
// WHY THIS IS SEPARATE FROM ecosystem.light.config.cjs, given both currently run the same five apps:
|
|
// the exclusions mean different things. On macOS officer-vnc cannot run — there is no Xorg to mirror.
|
|
// On a Linux light install it could run perfectly well; you have chosen not to. Those diverge as soon
|
|
// as one profile gains something the other cannot have, and collapsing them would lose the reason.
|
|
//
|
|
// Start with: pm2 startOrRestart ecosystem.mac.light.config.cjs
|
|
|
|
const { defineProfile } = require('./ecosystem.profile.cjs');
|
|
|
|
module.exports = defineProfile({
|
|
file: 'ecosystem.mac.light.config.cjs',
|
|
|
|
include: [
|
|
'officer', // the app: SPA, /api, websockets
|
|
'officer-anthropic-proxy', // holds the Anthropic credential, forwards to api.anthropic.com
|
|
// Spawns `claude`. Reads the proxy secret from disk, so it needs no ordering against the proxy
|
|
// above: if the secret is not written yet it warns and re-reads before the next spawn.
|
|
'officer-agent',
|
|
'officer-opencode', // the alternative agent
|
|
// The terminal. Runs under node rather than bun — node-pty binds a native addon built against
|
|
// node's ABI. That detail lives in ecosystem.config.cjs, not here.
|
|
'officer-pty',
|
|
],
|
|
|
|
excluded: {
|
|
// Cannot run on macOS at all.
|
|
'officer-vnc': 'mirrors an Xorg display with x11vnc; macOS has no Xorg',
|
|
|
|
// Left the baseline on 2026-08-11, on both light profiles together. It genuinely needs nothing installed
|
|
// locally — it points at a remote instance over the network — but a baseline process shows up in the dock
|
|
// and the Permissions screen whether or not a URL was ever given, so "is Gitea here" had two answers. It
|
|
// is an app-store install now: `existing` mode, URL and token, same as any other remote service.
|
|
'officer-gitea': 'fronts a remote instance; installed from the app store with its URL and token',
|
|
|
|
// Would run, but needs something setup_mac_light.sh deliberately does not install.
|
|
'officer-email': 'needs the mbsync/IMAP stack setup_mac_light.sh does not install',
|
|
'officer-caldav': 'supervises Radicale, which setup_mac_light.sh does not install',
|
|
'officer-music': 'the ffprobe indexer works, but a full ~/Music index is expensive to start by default',
|
|
|
|
// Fronts a container or daemon a laptop is not running.
|
|
'officer-vault': 'reverse-proxies a self-hosted Vaultwarden container',
|
|
'officer-slskd': 'supervises the slskd daemon',
|
|
'officer-headscale': 'fronts a headscale server',
|
|
'officer-transmission': 'fronts a transmission daemon',
|
|
'officer-invoiceshelf': 'fronts an InvoiceShelf container',
|
|
'officer-jellyfin': 'fronts a Jellyfin container',
|
|
|
|
// Needs an owner-configured external service.
|
|
'officer-memos': 'needs an owner-configured Memos instance URL and token',
|
|
'officer-photos': 'needs an owner-configured Immich instance URL and API key',
|
|
|
|
// Deliberate, for what it holds or who feeds it.
|
|
'officer-notify': 'its producers are the queue and the email/agent sidecars; nothing to notify about',
|
|
'officer-wallet': 'holds seed and node credentials; not on a laptop',
|
|
},
|
|
});
|