Engineering teams

Shared review context without turning local work into a hosted team account.

Give operators a mission picture for parallel agent work while keeping prompts, paths, credentials, and review state local by default.

Engineering teams need a common way to understand what agents are doing, where review is needed, and which local signals support a change.

Before and after

What changes for Engineering.

Each row keeps the pain point, the FactionOS path, and the implementation boundary together so role copy does not turn into a broad hosted-service claim.

  1. 01 Mission status

    Before Status is inferred from terminal scrollback, chat updates, or stale PR notes.

    After A local cockpit can summarize active lanes, mission posture, and review checkpoints.

    Boundary Cockpit visibility is product runtime behavior, not a live public website feed.

  2. 02 Review context

    Before Reviewers ask what changed, which tool ran, and why an agent moved to the next step.

    After File, tool, validation, approval, and lifecycle signals stay attached to the mission.

    Boundary Signals must stay bounded and avoid raw secrets, full source, or broad path dumps.

  3. 03 Parallel work

    Before Planner, builder, and reviewer agents drift because ownership is not visible.

    After Lanes, subagent lineage, and checkpoints give operators a shared map.

    Boundary Lineage is event context, not a promise that every external provider is supported.

  4. 04 Failure handling

    Before Broken hooks or validation gaps become invisible until someone audits manually.

    After Diagnostics and validation state surface as visible local product signals.

    Boundary Diagnostics copy must expose failure states without leaking sensitive output.

Relevant surfaces

Surfaces with explicit boundaries.

These mappings distinguish local runtime behavior, optional collaboration, outbound-only adapters, static demo previews, and docs-owned setup detail.

Cockpit

apps/web cockpit

Availability local

Mission lanes, agent roster, review state, and bounded timeline context.

Guardrail Not a hosted workspace or team account surface.

Features

Hooks

hook event pipeline

Availability local

Prompt lifecycle, tool activity, validation, and file-touch signals become local events.

Guardrail No default upload of prompt bodies, credentials, or source files.

How It Works

War Room

optional collaboration

Availability optional

A team-readable mission view can exist only when deliberately configured.

Guardrail War Room collaboration is optional and separate from the local baseline.

Security

Proof examples

Static examples, not live telemetry.

The examples show product meaning and review posture while keeping demo data, local runtime data, and public website copy separate.

Static example

Review checkpoint row

A mission row can show owner, status, validation state, and next review action.

Evidence
Useful when a reviewer needs context before approving a risky local change.

Boundary Example rows are authored copy and are not live team telemetry.

Boundary

Local privacy reminder

Role copy keeps prompt bodies, local paths, credentials, and source code out of website claims.

Evidence
Useful when adopting agent visibility in privacy-sensitive repositories.

Boundary Local-first behavior is the baseline unless a later integration is explicit.

Team path

Inspect the surface map, then open the synthetic demo.

Use product and features pages to compare the local cockpit and review surfaces, or open the external demo to inspect a synthetic version of the flow.

Boundary The zero-install demo is synthetic and separate from real local sessions. It is not a hosted customer workspace, analytics stream, or team-management surface.