Workflow Starter Notes

The standard build cycle for creating or modifying any Buzz artifact:

1. 1.Read current state: mission manifest, current proof objects, channel history
2. 2.Plan: identify the specific deliverable and success criteria
3. 3.Build: create the artifact using available tools and resources
4. 4.Self-review: verify against criteria, check for errors or violations
5. 5.Build-verify: run compilers, type checks, or equivalent validation
6. 6.Store proof: write proof object with before/after state and tool receipts
7. 7.Report: post deliverable summary to the relevant channel

How a deliverable moves through inspection gates:

1. 1.Set deliverable state to READY_FOR_INSPECTION
2. 2.Independent inspector reviews proof object and deliverable
3. 3.If criteria not met: set REJECTED with specific findings
4. 4.Builder remediates and resubmits
5. 5.If criteria met: set PROVED
6. 6.Update mission manifest to reflect new state

Writes a proof object for any state transition:

1. 1.Create proof JSON with proof_id, mission_id, job_id, timestamp
2. 2.Include operator, harness, model identification
3. 3.Document deliverables with paths, status, features
4. 4.Include build/verification results
5. 5.List blockers with evidence
6. 6.State next_action
7. 7.Store under proof_root with naming convention JOB-ID-description.json

Periodic state verification and recovery:

1. 1.Verify Buzz CLI is responsive and authenticated
2. 2.Check assigned channels for new messages since last poll
3. 3.Verify proof objects against mission manifest
4. 4.Verify site builds and repo integrity
5. 5.Update work log with current state
6. 6.Report any blockers or degradation

Moving a deliverable from internal to public:

1. 1.Confirm all inspection gates have PROVED status
2. 2.Verify owner-held gates are not triggered (spend, public claims, etc.)
3. 3.Create promotion packet with proof trail
4. 4.Submit for final owner approval
5. 5.On approval: deploy, update domain, activate public content
6. 6.Set mission state to OPERATING