ToastMachine Documentation
ToastMachine Documentation
ToastMachine Documentation
This repository contains the ToastMachine engineering wiki, with partial Worker references, source-backed test catalogues and developing architecture, protocol, data and operations guidance.
Worker references and test specifications contain substantial source-backed material. Topic pages include partial implementation baselines; remaining prompts and unknowns are not established behavior. Source inspection is not test execution or deployment verification.
The Markdown documentation audit inventories all project Markdown across the sibling repositories and records corrections and remaining work. The pre-existing performance and caching audit provides additional analysis and measurement limitations.
Documentation index
Architecture
- Architecture Overview
- Data Flow
- Trust Boundaries
- ADR 0001: Multi-Corpus Identity and Lifecycle Semantics
Workers
Protocol
- API Reference
- Identity and Authentication
- Contributions
- Pagination and Synchronisation
- Errors and Retries
- Compatibility
- Fork and selective-import provenance
Data
- Storage
- Schema
- Data Invariants
- Ledger and Sequencing
- Retention and Immutability
- Portable binary segments
Testing
- Testing Strategy
- Test Inventory
- Security Testing
- Failure and Recovery Testing
- Registration Worker test specification
- Ingress Worker test specification
- Corpus Worker test specification
- Resources Worker test specification
- Events Worker test specification
- MCP Worker test specification
Integrations
Operations
Development
Templates
Documentation conventions
- Use Markdown, one H1 per page and a consistent hierarchy of headings.
- Use relative links for repository documentation.
- Keep topic placeholders lightweight; use the reusable Worker template when expanding Worker references.
- Keep documentation status and last-reviewed metadata current. A review date alone does not verify a claim.
- Cite source locations, revisions and relevant verification results when adding technical claims.
- Apply the template’s evidence statuses to claims: Verified, Code-confirmed, Intended, Unknown or Not applicable. Evidence status is separate from page completion status.
- Identify unknowns explicitly. Do not infer architecture, behaviour, dependencies or guarantees from names or planned scope.
- Never include secrets, credentials or sensitive configuration values.