Personal control setup
Mothership
Mothership is the operating layer I use to keep products, role agents, evidence and human decisions in one coherent loop.
Current status
Private working setup
This is a transparent account of a working setup, not a product or security certification.
Once several agents and products are moving at the same time, the hard problem is no longer prompting. It is knowing what owns the work, which context applies, what has been verified and which decisions still belong to a person.
How it works
Capture
An idea, feature, bug or live signal enters with a source.
Route
The correct Project, role and evidence contract are selected.
Work
Venture, Build or Ops follows its own bounded procedure.
Verify
Tests, review and exact candidate evidence are attached.
Decide
A person retains the final consequential gate.
Operating principles
Use the native ledger
Hermes Projects hold product context. Native Kanban holds tasks, dependencies and evidence. Mothership composes those primitives instead of creating a second workflow database.
Separate roles from products
Venture, implementation, independent QA, review and operations are different responsibilities. Shared roles work across projects; product-specific operations stay with the product.
Keep authority outside the model
Agents can prepare work and evidence. Consequential changes still pass through an explicit human gate. Product systems remain authoritative for customers, permissions and live state.
Read status without creating power
Portfolio views summarize bounded project and task state. A status screen is not an approval surface and does not grant an agent extra authority.
Evidence ledger
Private artifacts are described, not exposed. Public references establish the underlying platform primitives, not the behavior of my implementation.
Claims tied to primary artifacts
MS-01
The plugin reads native Hermes state instead of creating a second lifecycle store.
- Primary evidence
- Private primary artifact: the status façade dispatches to Project and Kanban readers. An isolated contract asserts that a status read creates neither a Mothership directory nor a database.
- Verified
- Included in 78 Python contracts; the full suite passed on 29 August 2026.
- Boundary
- This verifies the plugin boundary in isolation. It does not certify every live installation or the upstream Hermes runtime.
MS-02
Portfolio status is bounded and reports incomplete evidence as incomplete.
- Primary evidence
- Private primary artifact: contracts cap task output, bound nested comments, runs and attachments, omit undeclared fields, and mark truncated or stale snapshots.
- Verified
- The 78 Python contracts and 11 desktop contracts passed on 29 August 2026.
- Boundary
- A bounded read model reduces accidental exposure and false certainty; it is not a security audit.
MS-03
A gate is not reported satisfied from a plausible comment alone.
- Primary evidence
- Private primary artifact: contracts reject evidence from the wrong profile or an unfinished run, and accept matching commit-bound evidence from a completed reviewer run.
- Verified
- The gate-evidence contracts passed inside the same 78-test Python suite on 29 August 2026.
- Boundary
- This checks evidence identity and run state. It does not replace human judgment at merge or release.
What this does not prove
- This documents my current operating model. It is not a release certification or a claim of customer-scale operation.
- The public view omits private product context, machine topology and implementation details.
- Human gates reduce authority risk; they do not by themselves prove that every underlying system is secure or reliable.
Related framework