Scope approval, dedicated idea chats and versioned Git checkpoints
Accepted user workflow with implementation details supplied by the manager.
User decision
Each idea has its own chat and is committed. Idea/research scope is signed off with the user in its owning chat before that chat notifies the manager; the manager then authorizes start. Preserve changes and clarifications over time. Initialize Git if needed and commit the initial harness.1
Manager implementation
The detailed workflow is maintained at repository path harness/workflow.md. Use immutable scope/vNNN.md documents, separate user and manager approval receipts tied to a version/hash, dated inputs, an editable brief, a change register, and additive Git checkpoints. The manager owns Git writes in the shared checkout to avoid competing commits. Material scope changes repeat the two gates; ordinary clarification remains recorded without forcing approval of unchanged scope.
The human instruction explicitly authorizes owning project chats to notify the manager about scope approval and results. Every new idea's dedicated chat is covered by the standing request; no new permission question is needed just to create it.
Transition
Git was already initialized on main with no commits when this instruction arrived. Existing harness, IDEA-001 and completed landscape work predate the new gate and are retained without retroactive approval claims. IDEA-002 is being directed to checkpoint partial findings, prepare a scope version and await approval. Future phases follow this workflow.
-
Original instruction in the manager chat. Mechanisms such as scope hashes and Git ownership are implementation choices, not quotations from the user. ↩