Observe-first onboarding — connect existing repos without interference (quiet mode, UI-operated projects)

Teams with a working SDLC must be able to connect Facility without it touching their repositories, and then opt in progressively. This is the brownfield adoption path — the difference between "rip out your process to try this" and "connect it in five minutes and click a button when curious". The platform lane already covers most of it; the gaps are noise and defaults.

What already works (verified on a live deployment)

• A repository connected without kickstart vendors nothing and provisions nothing.
• Comment commands are ignored by default: laneFor() routes /architect-style comments to the platform only when render_answers.execution_lane is explicitly set.
• The control-plane trigger (POST /v1/projects/:id/issues/:number/trigger) deliberately bypasses the lane gate, so operating from the UI works today.
• The issue mirror is read-only by design; multi-repo aggregation is #25.

Gaps for a true observe-first mode

1. Quiet mode (per project or per repository): today even a UI-triggered run posts an acknowledgement comment, and the architect maintains progress and publishes its plan as issue comments. Quiet mode: no acknowledgement, no progress comments, the plan reviewed in the platform, and at most one opt-in summary comment. Pull requests and human feedback still flow through GitHub.
2. Scheduled crew enabled on day one: seedProjectHarnessAgents creates project-owner and learning agents on daily schedules, enabled. Observe-first projects need them off by default, or an explicit project-level autonomy setting that gates schedules.
3. execution_lane needs a product surface (project settings) rather than a database write, keeping the safe default it already has.
4. Command namespacing: a configurable prefix (for example /fx architect) so comment mode can coexist with an incumbent automation that already owns /architect-style commands.
5. Least-privilege install guidance: observe-only projects do not need write access to contents, issues or pull requests — document a read-scoped App variant or split the scopes.

Start by tracing the existing laneFor() gate, POST /v1/projects/:id/issues/:number/trigger, seedProjectHarnessAgents, and render_answers.execution_lane behavior. Define the project or repository settings and permission guidance needed for quiet, observe-first operation, then verify that UI-triggered runs avoid unsolicited comments and scheduled agents remain safely disabled until opted in.