# Tolowa Machine Hydrate — Agent Ingest Document

Version: pilot-0.2
Status: pre-release — design-partner pilot
Canonical URL: https://tolowastudio.com/machine-hydrate/ingest

## What exists today, and what does not

Read this before relying on anything below. A safety document that overstates
its own readiness is the first thing that should not be trusted.

BUILT AND TESTED:
- A payload generator that reads an operator-owned profile and emits skills, a
  harness config, a memory scaffold, and install steps.
- A scanner that gates that generator's OWN output and destroys the payload
  rather than emit one carrying another operator's identity — including
  identity-shaped values (account ids, database ids, home paths) that carry no
  brand name and that a keyword search cannot see.
- An intake that produces the profile by asking, and blocks the build on any
  question left unanswered rather than defaulting it.
- Schema-driven creation of the operator's own database structure, generating
  the operator's own ids. No ids are copied.
- A one-way mirror of the operator's library into local files they own.

HOW IT IS DELIVERED:
- The toolkit is a private repo: github.com/tolowa-studio/machine-hydrate.
  Access is granted per operator. Clone it, run the intake, and the generator
  builds YOUR payload on YOUR machine from YOUR answers. Nothing
  tenant-specific is transmitted, and no one else needs to be in the loop.

NOT BUILT YET:
- A tagged, checksummed PUBLIC release. There is no anonymous download, and
  nothing here should claim there is. Roughly half the shipped skills are
  third-party and their redistribution terms have not been reviewed — which is
  the honest reason the repo is private, not a coyness about the method.

## Objective

Help the operator rebuild an agent-ready Mac from a clean, client-owned baseline. The result may include approved tools, agent harnesses, portable rules and skills, repositories, a Notion operating library, a local context mirror, secrets references, backup, restore, updates, rollback, uninstall, and optional time-bounded remote support.

## Non-negotiable boundary

Transfer the operating method. Never transfer another person's data, credentials, tenant IDs, absolute home paths, private examples, account ownership, recovery keys, paid-account coupling, or invisible dependencies.

The operator owns the Apple identity, GitHub account or organization, Notion workspace, storage, password manager, backups, AI accounts, repositories, data, and recovery keys.

## Operating rules

1. Start in discovery mode. Do not mutate the machine or any external service during intake.
2. Never request secret values in chat, a prompt, a Markdown file, Git, Notion, or logs.
3. Verify the active account and workspace before every external write.
4. Use official OAuth where supported and least-privilege service identities for unattended work.
5. Generate tenant bindings from schemas. Never copy database IDs, tokens, or paths from another operator.
6. Show a dry-run diff before applying the baseline.
7. Pause for macOS privacy, security, disk-encryption, account-ownership, and remote-access gates.
8. Treat missing, ambiguous, timed-out, or malformed dependency responses as failures.
9. Do not call the hydrate complete until backup restoration and owner detachment are proven.
10. Preserve an uninstall and exit path that removes Tolowa access without deleting operator data.

## Supported delivery lanes

Choose one lane in the Machine Profile:

- self-serve: the operator and their agent use this document and a verified release; Tolowa has no machine access. NOT OPEN YET — no public release is published. Do not tell an operator to download one.
- assisted-session: the operator grants named, time-bounded, revocable access for a scheduled support window.
- managed-workstation: persistent administration exists only under a separate written scope, access policy, and audit requirement.

Default to self-serve. Do not enable remote access merely because it is convenient.

## Phase 0 — Recovery inventory

Ask these questions one at a time and record answers without secrets:

1. What Mac model and macOS version are being configured, and is the machine already in use?
2. What survived in Notion, iCloud, Google Drive, OneDrive, Dropbox, GitHub, browser sync, email, external disks, and vendor accounts?
3. Which password manager, if any, does the operator own?
4. Which Notion workspace is the permanent operating tenant?
5. Which AI tools will the operator actually use each week?
6. Which storage provider should own working files?
7. Which data classes must agents never access?
8. What single real workflow will prove the system on day one?
9. Is optional time-bounded Tolowa support desired?
10. Is there any old device, backup, external disk, cloud export, or vendor copy that may contain recoverable data?

Do not confuse data missing from the new Mac with data proven lost.

## Required Machine Profile

Before making changes, produce this profile and show it to the operator:

~~~yaml
version: 1
owner:
  name: unresolved
  github: unresolved
  notion_workspace: unresolved
machine:
  model: unresolved
  architecture: unresolved
  macos: unresolved
  already_in_use: unresolved
library:
  provider: notion
  local_mirror: git
storage:
  provider: unresolved
secrets:
  provider: unresolved
  plaintext_allowed: false
backup:
  local: unresolved
  offsite: unresolved
  restore_canary: required
agents:
  selected: []
  default_approval: suggest
remote_support:
  mode: self-serve
  persistent_tolowa_admin: false
first_workflow:
  name: unresolved
protected_data_classes: []
~~~

## Proposed change plan

After the profile is approved, produce a dry run with these sections:

- accounts to confirm or create
- packages and applications to install
- repositories to create or clone
- configuration files to generate
- Notion structures to create or bind
- OAuth connections and exact scopes
- secret references required, without values
- backup targets and restore-canary procedure
- optional remote-support policy
- tests, rollback, and uninstall steps
- estimated manual prompts and operator decisions

Do not apply the plan until the operator approves it.

## Acceptance gates

The hydrate passes only when:

1. A clean machine reaches the declared state from a generated payload and the operator-owned profile. (When a tagged, checksummed release exists, verify its checksum before use; until then the payload is built and handed over directly.)
2. An automated scan of the generated payload finds no Tolowa credentials, tenant IDs, personal paths, private examples, or secret material — checked as a build gate that fails closed, including identity-shaped values carrying no brand name. A payload that fails is destroyed, not shipped.
3. The Notion structure is created or mapped from schemas without copied UUIDs.
4. A real operator workflow completes with human approval.
5. A selected dependency is disconnected and the failure is visible and safe.
6. A selected business folder restores to a separate clean environment with matching hashes.
7. A release update applies, rolls back, and can be re-applied.
8. Tolowa access can be revoked without breaking the operator's system.
9. The operator repeats the first workflow without Tolowa.

## Stop conditions

Stop and ask for the operator's decision if:

- account ownership is ambiguous;
- the active Notion workspace cannot be verified;
- a script requests a secret value in plaintext;
- an artifact cannot be verified;
- the dry run includes destructive cleanup;
- backup or recovery-key storage is unresolved;
- remote access would be broader or longer-lived than the approved policy;
- a proposed skill requires filesystem, network, or shell access outside its declared scope;
- the baseline contains another person's path, tenant binding, credential name, or private context.

## Completion report

Return:

- the final Machine Profile;
- installed release and lockfile versions;
- accounts and data ownership table;
- verification evidence for each acceptance gate;
- backup and restore evidence;
- remaining manual steps;
- known limitations;
- exact revocation, rollback, and uninstall instructions;
- a clear status of PASSED, FAILED, or NOT YET PROVEN.

Never round an incomplete or unverified hydrate up to PASSED.