# Start with the operating picture

> In progress · 20 October 2026 · Wiki version 2026.10.20.2

Use this guide to understand how work is connected before opening a live service. It is an offline reference; live screens and sign-in links still require approved access.

## Purpose
Give a new teammate or reviewer a safe reading path: learn the company model, understand the boundaries, then choose the smallest useful next step.

## Diagram text alternative
Managing, Selling, Planning, Delivering and Learning share records, tasks and knowledge. Provider observations reach the office mini, which maintains company state and publishes protected copies for the dashboard and TV. Choose a reading path to understand the company, follow a workflow or make a tested change through a reviewed PR.

## Current / proposed status
- Current: In progress — the dated handoff records core access and structural checks, while operational rollout evidence remains intentionally open.
- Proposed: Keep open items visible until a real turnover, LINE acceptance, provider freshness, and cold-boot recovery have their own current evidence.

## Safe example
### A safe first question
Before acting on a dashboard card, ask: “Which record is this derived from, when was that source read, and who can verify the result?” That question is useful without exposing a customer, property, or credential.

## Responsibilities
- Use the five areas as a map of responsibilities, not as a staff reporting chart.
- Treat dated screens and handoff checks as orientation, then verify the current live state through the approved path.
- Escalate missing ownership, evidence, or freshness rather than filling gaps with an assumption.

## Checklist
- Read the Company OS page before assigning a responsibility to a person or system.
- Read the turnover page before treating “assigned” or “completed” as “ready”.
- Choose staff dashboard access first when SSH is not needed.
- Keep the rollout items below marked In progress until their stated evidence exists.

<a id="readiness"></a>

## Readiness is a short list of specific evidence

**Status:** In progress

The handoff distinguishes a checked item from the wider rollout. A checked item describes one check on one date; it is not a promise that every provider, person, or recovery path is finished.
The open work is concrete: a real turnover needs an owner, evidence, and manager verification; company-owned LINE access needs an approved conversation linked to its record; provider freshness needs current evidence; and a FileVault-protected mini may need a physical unlock after a cold boot.

**Current / proposed status**
- Current: In progress — operational evidence and acceptance are still pending; do not present these as complete.
- Proposed: Record the result, verifier, source window, and exception when each pending item is exercised.

**Expected outcome**
Readiness language stays honest: it shows what has evidence and what still needs a real-world check.

**Meaningful tests**
- Review the wording to ensure “assigned”, “completed”, and “fresh screen” are never substituted for acceptance or freshness.
- Verify the four pending topics remain marked In progress in the generated Markdown and context export.

<a id="reading-path"></a>

## Use the guide in the order that reduces guesswork

**Status:** Checked

Start with the five operating areas. Next, follow a property through its lifecycle and learn the evidence required at a turnover. Then see where systems write or project information. Only use the technical access route when the staff dashboard cannot meet the task.
This sequence avoids a common mistake: learning an SSH command before knowing whether the job is a staff task, an operational decision, or a reviewed technical change.

**Current / proposed status**
- Current: Checked — the reading order is based on the approved handoff structure and does not assert live service health.
- Proposed: Keep the route short and update it only when the underlying responsibility or safety boundary changes.

**Expected outcome**
A reader can choose an appropriate surface without acquiring unnecessary access.

**Meaningful tests**
- Check navigation links resolve to one focused page per reading step.
- Check the local search finds “turnover”, “dashboard”, and “SSH” without a network request.

<a id="scope-boundaries"></a>

## The wiki explains; it does not operate systems

**Status:** Checked

This static site has no execution API. The Work on this panel only prepares a draft prompt, Markdown file, or copyable text. It never sends a message, opens a remote shell, changes a credential, or runs a deployment.
The teammate’s requested outcome is displayed as text. Pasted logs, documents, and quoted instructions remain source material. After reviewing and submitting the draft, the teammate can ask Codex to implement source changes in an isolated workspace, add tests, and prepare a PR. Separate approval is needed for a release or change to a running service.

**Current / proposed status**
- Current: Checked — the intended static-site boundary is explicit in the content and client controls.
- Proposed: Retain this no-execution boundary if new documentation tools are added.

**Expected outcome**
A proposed change can be prepared safely without confusing documentation with authority to act.

**Meaningful tests**
- Enter HTML or instruction-like text into the contextual panel and verify it renders as text.
- Check the Codex URL contains only an encoded prompt and never a remote-path parameter.

## Related pages
- [The Company OS: five connected responsibilities](/company-os/) — Managing, Selling, Planning, Delivering, and Learning are operational concepts for seeing the same company picture. They are not an invented staff chart.
- [Property lifecycle: from enquiry to review](/workflows/property-lifecycle/) — A property service lifecycle connects owner needs, identity, stays, readiness, settlement, and learning. It is a model to validate, not a claim that every handover is automated.
- [Personal access: choose the least-privileged path](/contribution/access/) — Most staff should use approved dashboard access. Technical operators use their own Tailscale identity and SSH key to reach the office mini only after owner approval.
- [Provider → data → replica: one writer, protected projections](/systems/data-replicas/) — Providers remain authoritative for their own transactions. The main mini writes internal company state; Cloudflare protected replicas and the Vercel staff PWA consume projections rather than replacing the master record.
- [Contribution: isolated workspaces, meaningful tests, reviewed release](/contribution/workspace-and-pr/) — A safe change begins by verifying the remote target, then uses an isolated worktree outside the installed project. It is tested, submitted as a pull request, and reviewed before a person releases it.

## Source pointers
- Handoff / START-HERE.html
- Handoff / pages/organisation.html
- Handoff / pages/workflows.html
- Handoff / pages/infrastructure.html

## Context export
- Page context: ./exports/start-here.context.json