Co.PropertyTeam wikiCo.Property20 October 2026
Press slash to search. Arrow keys select a result.
Internal knowledge
Browse the wiki

Systems

Mac mini

Checked

The office Mac mini holds internal company state and runs configured operating processes. It is the authoritative writer for internal tasks, decisions, identity links, and audit state.

Download page Markdown
Interactive mapSelect a node to read its explanation. Use Work on this beside the section to prepare a change.
The Mac mini: authoritative writer and local operating core diagramA technical operator reaches the mini through approved Tailscale and SSH access. The mini owns local company and operational writes, publishes protected projections, and may require physical FileVault unlock after a cold boot.Approved operator — Personal access: choose the least-privileged pathApproved operatorTailscale + SSH — Personal access: choose the least-privileged pathTailscale + SSHMain mini writes — The Mac mini: authoritative writer and local operating coreMain mini writesLocal responsibilities — The Mac mini: authoritative writer and local operating coreLocal responsibilitiesCold boot boundary — The Mac mini: authoritative writer and local operating coreCold boot boundaryProtected views — Provider → data → replica: one writer, protected projectionsProtected views
The main mini writes company state; other views consume carefully scoped projections.Solid · information flowDashed rose · operator access
Read the diagram as text

A technical operator reaches the mini through approved Tailscale and SSH access. The mini owns local company and operational writes, publishes protected projections, and may require physical FileVault unlock after a cold boot.

  • Approved operator → Personal access: choose the least-privileged path
  • Tailscale + SSH → Personal access: choose the least-privileged path
  • Main mini writes → The Mac mini: authoritative writer and local operating core
  • Local responsibilities → The Mac mini: authoritative writer and local operating core
  • Cold boot boundary → The Mac mini: authoritative writer and local operating core
  • Protected views → Provider → data → replica: one writer, protected projections
What it does

Explain why the main mini owns writes, what local responsibility means, and why technical access requires a deliberate route rather than an assumed remote environment.

Responsibility

The main mini owns writes to internal company tasks, decisions, identity links, and audit state.

Next step

Treat the mini as the writer boundary and preserve the record source of each projection.

The main mini owns the internal write boundary

Checked

The office Mac mini is the authoritative writer for internal tasks, decisions, identity links, and audit state.

Read the details

The office Mac mini is the authoritative writer for internal tasks, decisions, identity links, and audit state. Its local stores have distinct company, knowledge, operational, company-record, and portfolio-observation responsibilities. This separation helps explain why a projection should not be mistaken for the original record.

A staff dashboard, Cloudflare replica, or Vercel application can make a useful view available without taking over the write role. If a projected value needs correction, investigate its source and approved writer rather than trying to patch the display.

Current
Checked — this ownership description is directly supported by the handoff architecture.
Proposed next state
Maintain an explicit source and writer boundary whenever a new projection or integration is proposed.
Expected outcome
Data changes can be traced to the right authoritative environment and reviewed safely.
Checks to include when changing this section
  • Check architecture text says “mini owns writes” and does not assign master-record status to replicas.
  • Check proposed connector changes identify duplicate, failure, and freshness behavior.

Cold boot is a recovery condition, not a background detail

In progress

FileVault protects the mini at rest.

Read the details

FileVault protects the mini at rest. After a cold boot, the machine may require physical unlock before network services can become available. That means a remote access route may be correct in normal operation but still be unavailable during this recovery condition.

The correct current status is pending until an approved, attended recovery exercise demonstrates the intended behavior. Do not claim an automated recovery path or unattended access merely because a normal SSH session has worked before.

Current
In progress — FileVault cold-boot recovery may need physical unlock and has not been asserted as complete.
Proposed next state
Run an owner-approved, attended recovery check and record only its outcome and necessary next steps in the authorised operations record.
Expected outcome
The team knows when a physical unlock is needed and avoids relying on an untested recovery assumption.
Checks to include when changing this section
  • Check cold-boot content uses pending language in all exports.
  • Check any recovery procedure avoids publishing credentials, private keys, or runtime logs.

Local viewer paths require the secured connection

Checked

The mini viewer exposes `/admin`, `/planning`, `/health`, `/reports`, and `/tv` on loopback port 8790.

Read the details

The mini viewer exposes `/admin`, `/planning`, `/health`, `/reports`, and `/tv` on loopback port 8790. These paths are intended to be reached through an approved SSH tunnel; they are not public links for an unconnected laptop.

A healthy-looking viewer page is still a view. Use the record, source freshness, and relevant operating boundary before turning an observation into a write or acceptance decision.

Current
Checked — the loopback viewer target is documented as a secured connection surface, not a public deployment.
Proposed next state
Keep tunnel instructions scoped to approved operators and do not publish access material in the wiki.
Expected outcome
Operators know the difference between a local viewer path and a public staff service.
Checks to include when changing this section
  • Check loopback paths only appear with the SSH-tunnel safety description.
  • Check no source export includes a token, private key, or shell command that changes runtime state.

Apply with care

A concrete safe example

Example, responsibilities & checklist

A safe maintenance boundary

If a dashboard view seems wrong, first verify the appropriate source and record path. Do not edit the installed mini runtime from a personal workspace. A reviewed change starts in an isolated worktree after hostname, path, and status checks.

Responsibilities

  • The main mini owns writes to internal company tasks, decisions, identity links, and audit state.
  • Local stores retain separate company, knowledge, operational, records, and portfolio responsibilities.
  • Cloud replicas and staff applications consume protected projections rather than becoming the master record.
  • Technical operators use personal approved access and follow the contribution contract.

Checklist

  1. Treat the mini as the writer boundary and preserve the record source of each projection.
  2. Verify host, project path, and repository status before any technical work.
  3. Create a worktree outside the installed project; never modify the installed runtime.
  4. Plan for a physical unlock path when FileVault affects cold boot recovery.
Expected outcome

A contributor understands where company state is written and avoids treating replicas or personal machines as an authoritative replacement.

Traceability without sensitive material

Source pointers and exports

This page expands the approved handoff into plain-language guidance. It does not include runtime logs, credentials, databases, private evidence, internal QA artifacts, or developer planning history.

Documentation references
  • Handoff / pages/infrastructure.html
  • Handoff / pages/access.html
  • Handoff / START-HERE.html
Page MarkdownPage context JSON