A local browser surface for watching missions, agent lanes, lifecycle events, and review state without turning the public website into a hosted app.
- Role
- Operator view for active agent work.
- Mission and lane visibility for parallel agent work.
- Status rings and bounded timeline rows instead of raw terminal scrollback.
- Review checkpoints that keep task intent visible.
Boundary The cockpit is product runtime UI, not this static page. Local state is read only when the local install is running.
See cockpit features -> Development hooks turn prompt lifecycle markers, tool activity, file-touch signals, and validation outcomes into structured local events.
- Role
- Source of local workflow signals.
- Lifecycle events become bounded records.
- File and command signals stay attached to local context.
- Failures can be shown as visible states rather than silent gaps.
Boundary Hook ingest starts on the developer machine and does not imply default upload of prompts, paths, credentials, or source files.
Follow the ingest flow -> Command-line workflows let operators run, inspect, and validate local FactionOS behavior from the same terminal context as the codebase.
- Role
- Developer entry point and local control plane.
- Start and inspect local product surfaces.
- Run validation gates close to the workspace.
- Keep operator actions explicit instead of hidden automation.
Boundary CLI output shown here is authored sample copy. Real terminal output is not collected by the public website.
Review setup flow -> Shared event contracts keep hooks, server state, adapters, and UI surfaces aligned as product boundaries become more complex.
- Role
- Typed connective tissue between surfaces.
- Consistent event names and payload shapes.
- Clear separation between local snapshots and optional outbound notices.
- Reduced drift between CLI, server, cockpit, and adapters.
Boundary Protocol descriptions do not expose repository content or user-provided code from a visitor browser.
Inspect the architecture -> A collaboration surface can summarize team-visible mission state when deliberately enabled, with redaction and service boundaries treated as product requirements.
- Role
- Optional shared view for coordinated work.
- Team-readable mission state when configured.
- Redaction posture belongs next to collaboration claims.
- Local-only operation remains the baseline product story.
Boundary War Room collaboration is optional and separate from the local baseline. It is not a default hosted account, public replay service, or blanket storage promise.
Review trust boundaries -> Discord, Telegram, and generic HTTPS adapters are optional outbound paths. They can send narrow notifications to external systems such as team chat or downstream automation after an operator opts in.
- Role
- Optional external notification path.
- Payloads must be explicit and bounded.
- External destinations remain separate from the public website.
- Operators control whether a notification path exists.
Boundary Adapters stay outbound-only in this overview. They are not inbound command channels, visitor analytics, or automatic telemetry.
Compare adapter scope -> The public demo is a separate synthetic preview for inspecting product feel without connecting to a visitor workspace or hosted runtime session.
- Role
- Zero-install product preview.
- Product-like UI without local setup.
- Deterministic sample data for public inspection.
- Clear separation from real prompts, paths, and replay data.
Boundary The zero-install demo is synthetic and separate from real local sessions. It does not prove broad hosted media readiness or live customer telemetry.
Understand demo scope ->