Guide 2: grow when needed
Outline only. Add a feature for an observed need and develop its proof before claiming support.
Status: outline only. No advanced feature procedures, runtimes, connectors, workers, or schedules are implemented by this guide.
Entry point
Use the Guide 1 proof record to identify demonstrated needs and unresolved limits. Completing three to five real tasks is a useful suggestion, not a gate. Establish approved storage and a tested backup before valuable work. Add a feature when its trigger appears and verify its own proof requirement.
Feature triggers and required proof
| Feature | Trigger | Proof to develop before claiming support |
|---|---|---|
| Decisions | A choice is durable, consequential, or repeatedly re-explained. | A later session retrieves the accepted rationale, authority, and scope from files. |
| Inbox and outbox | Intake or review is difficult to track. | A sample item moves from receipt to review with one accepted result and no lost work. |
| Lead | Prioritization or coordination is causing missed work. | A bounded trial shows priorities, assignments, accepted results, and unresolved work. Three open tasks is an example, not a threshold. |
| Specialists | Recurring work needs different authority or quality criteria. Try a skill first if only the procedure differs. | Compare the resulting artifact against the specialist contract. Verify separate execution only if claimed. |
| Skills | A procedure repeats and has describable inputs, evidence, and done-when criteria. | Run the procedure on representative inputs and inspect outputs and failure behavior. |
| Model tiers | Observed quality, latency, or total cost justifies a change. | Compare successful-task quality and total usage including setup, retries, verification, and handoff. Keep vendor mappings in adapters, linked from AGENTS.md. |
| Journal | Cross-task history becomes useful. | Recover a historical event and its evidence. Individual task work logs remain authoritative for their tasks. |
| Second tool | A transfer is useful. | Test both named directions with saved files, returned artifacts, and canonical reconciliation before claiming bidirectional support. |
| Second person, device, or process | Another writer can touch canonical state. | Establish ownership and conflict recovery before concurrency. Use two proposals based on the same revision, accept one, preserve the stale one for reconciliation. |
| Backups and history | Before valuable real work. | Restore into a clean folder and actually resume from it. A copy alone is insufficient. Include protection against loss of the original drive. |
| Notes tools, including Mem | Capture or retrieval is inadequate. | Retrieve selected knowledge, deliberately promote accepted team knowledge to disk, and preserve provenance. External business records may remain authoritative in their approved systems. |
| Connectors or MCP | An authorized task needs another system and a simpler existing route is insufficient. | Verify the actual authorized operation and access scope. Installation alone is not proof. |
| Scheduling | A demonstrated recurring task warrants unattended execution. | Record real job ID, device binding, completed run, output readback, and observed failure handling. |
| Workers | Measured independent subtasks benefit from separate execution. | Start read-only with isolated proposals. Require assignment, actual separate execution, matching output artifact, and coordinator reconciliation. A printed run ID is insufficient. |
| Adapter refresh | Product, version, or permissions change. | Repeat the previously claimed operation in the new configuration and retain its scoped result and limitations. |
| Authority and data review | A new action, person, data class, or external destination is added. | Owner reviews scope and approved storage. Exercise a permitted action and an appropriate denied or unavailable case without using protected data in the public practice kit. |
State and storage
Durable task evidence and readable work history belong with the team files. Keep active locks, queues, databases, verbose runtime logs, and Git metadata in a local nonsynced working location. Sync may transport validated plain-file snapshots. Sync does not lock state, reconcile writers, prove peer delivery, or establish a tested backup. A same-drive backup cannot protect against loss of that drive.
Accepted team instructions and task state stay on disk. Keep product-specific settings and mappings in thin adapters. Plugins can supply skills and tools, but their executable connections and permissions are product-specific. Do not maintain a second authoritative task copy in a notes service.
Recovery experiments to design
Use disposable copies for competing-writer and interrupted-save experiments. Manual turn-taking does not establish automatic stale-write rejection. Only claim automatic behavior after an implementation and its test exist.
Introduce a controlled failure at the save boundary in a disposable copy. Preserve the last valid record and newer recoverable output. Killing a normal working session is neither safe nor a reliable save-boundary test.
Restore a backup to a clean folder and resume the actual task. For scheduling and worker execution, inspect real runs and persisted outputs. Separate documentation, installation, saved configuration, executed operations, and unrun checks in every result.
Scope exclusions
No dashboards, A2A, always-on worker pools, new database service, or two-way notes synchronization. WorkTeam and HomeTeam are future test cases, not evidence of a passed runtime. Their account, data, and storage permissions must be established separately. A shared file format grants no access.
Guide 1 publication prerequisite
Rob runs Guide 1 end to end in Codex and Claude Code on separate clean practice folders. Record product/version, elapsed time, exact capabilities, outcomes, failures, and memory controls. Those trials decide whether Guide 1 is published. Website tests and the structural task validator do not substitute for this evidence.