[Phase 2.1] Mesh-native provisioning via core intent protocol

Mark commented

2026-03-16 19:07:09 +00:00

Owner

Decision Lock

Provisioning is a standard mesh workflow (intent/contract/claim/result), not a bespoke signal subsystem.

Architectural Decisions

Mesh protocol is basic intent protocol (intent.discovered, intent.claimed, result.committed)
Ledger is a mesh resource
Nodes are mesh resource pointers
Workers are ephemeral execution instances (spawn -> execute -> exit)
No Clawdeploy dependency in active Phase 2 path

Scope

Introduce provision_worker intent type
Contract-first provisioning execution
Ephemeral worker lifecycle recorded in ledger
Router eligibility based on worker instance readiness
Integrate deterministic reliability bone for provisioning guardrails

Out of Scope

Phase 3 full bone compilation program
External orchestration dependencies

Acceptance Criteria

boundary.found can produce provision_worker intents
provisioning capability claims and executes via normal protocol
worker instance spawns, executes, exits, and is fully ledgered
settlement and retries operate by contract terms

Supersedes #29 (federation direction)
Distinct from #36 (Phase 3 bone compilation)
Closes #13 decision on Clawdeploy

## Decision Lock Provisioning is a standard mesh workflow (intent/contract/claim/result), not a bespoke signal subsystem. ## Architectural Decisions - Mesh protocol is basic intent protocol (`intent.discovered`, `intent.claimed`, `result.committed`) - Ledger is a mesh resource - Nodes are mesh resource pointers - Workers are ephemeral execution instances (spawn -> execute -> exit) - No Clawdeploy dependency in active Phase 2 path ## Scope - Introduce `provision_worker` intent type - Contract-first provisioning execution - Ephemeral worker lifecycle recorded in ledger - Router eligibility based on worker instance readiness - Integrate deterministic reliability bone for provisioning guardrails ## Out of Scope - Phase 3 full bone compilation program - External orchestration dependencies ## Acceptance Criteria - `boundary.found` can produce `provision_worker` intents - provisioning capability claims and executes via normal protocol - worker instance spawns, executes, exits, and is fully ledgered - settlement and retries operate by contract terms ## Related - Supersedes #29 (federation direction) - Distinct from #36 (Phase 3 bone compilation) - Closes #13 decision on Clawdeploy

Mark commented

2026-03-16 19:25:42 +00:00

Author

Owner

Implementation Complete ✅

All Phase 2.1 tasks implemented:

Files Modified

schemas/intent.schema.json - Added provision_worker intent and contract schemas
substrate/ledger.py - Added WorkerInstance dataclass, worker_instances table, and CRUD methods
substrate/bone.py - Added provision_reliability_guard_v1 bone with idempotency, retry, deadline, and cooldown enforcement
runtime/intent_router.py - Added route_with_instance_check() and check_ephemeral_instance_availability() for ephemeral worker routing

New Test File

tests/integration/test_phase2_1_provisioning.py - 17 integration tests covering:
- Worker instance lifecycle (create, update, query)
- Reliability bone (all guard conditions)
- Router instance eligibility
- End-to-end provisioning flow
- Idempotency enforcement

Test Results

17 passed in 1.80s

Ready for Next Phase

Schema foundation in place
Ledger persistence working
Bone guardrails active
Router can detect starvation and trigger provisioning

Next: Capability implementation for provisioning worker that uses these primitives.

## Implementation Complete ✅ All Phase 2.1 tasks implemented: ### Files Modified - `schemas/intent.schema.json` - Added provision_worker intent and contract schemas - `substrate/ledger.py` - Added WorkerInstance dataclass, worker_instances table, and CRUD methods - `substrate/bone.py` - Added `provision_reliability_guard_v1` bone with idempotency, retry, deadline, and cooldown enforcement - `runtime/intent_router.py` - Added `route_with_instance_check()` and `check_ephemeral_instance_availability()` for ephemeral worker routing ### New Test File - `tests/integration/test_phase2_1_provisioning.py` - 17 integration tests covering: - Worker instance lifecycle (create, update, query) - Reliability bone (all guard conditions) - Router instance eligibility - End-to-end provisioning flow - Idempotency enforcement ### Test Results ``` 17 passed in 1.80s ``` ### Ready for Next Phase - Schema foundation in place - Ledger persistence working - Bone guardrails active - Router can detect starvation and trigger provisioning Next: Capability implementation for provisioning worker that uses these primitives.

Mark commented

2026-03-16 19:44:56 +00:00

Author

Owner

Implementation Complete ✅

All Phase 2.1 tasks implemented:

Files Modified

schemas/intent.schema.json - Added provision_worker intent and contract schemas
substrate/ledger.py - Added WorkerInstance dataclass, worker_instances table, and CRUD methods
substrate/bone.py - Added provision_reliability_guard_v1 bone with idempotency, retry, deadline, and cooldown enforcement
runtime/intent_router.py - Added route_with_instance_check() and check_ephemeral_instance_availability() for ephemeral worker routing
capabilities/_muscle/worker_factory/template.yaml - Added provision_worker skill
capabilities/_muscle/worker_factory/run.py - Added _handle_provision_worker() for mesh-driven provisioning

Key Design

Provisioning = Factory worker claims provision_worker intent, creates worker registration + instance record
Execution = Worker claims real intent, mesh spawns process for execution
Separation of concerns: Factory registers candidates, mesh handles actual execution lifecycle

New Test File

tests/integration/test_phase2_1_provisioning.py - 17 integration tests (all passing)

Test Results

17 passed in 1.80s

What's Working

Factory responds to provision_worker intents
Reliability bone enforces idempotency, retries, deadlines
Worker instances tracked in ledger
Router can detect eligible instances
Full loop: boundary.found → provision_worker → factory → ledger → router

Next: Node Provisioning (#44)

Separate from worker provisioning
Add unstable.tail018ac4.ts.net as mesh node
Then workers can be provisioned on that node

## Implementation Complete ✅ All Phase 2.1 tasks implemented: ### Files Modified - `schemas/intent.schema.json` - Added provision_worker intent and contract schemas - `substrate/ledger.py` - Added WorkerInstance dataclass, worker_instances table, and CRUD methods - `substrate/bone.py` - Added `provision_reliability_guard_v1` bone with idempotency, retry, deadline, and cooldown enforcement - `runtime/intent_router.py` - Added `route_with_instance_check()` and `check_ephemeral_instance_availability()` for ephemeral worker routing - `capabilities/_muscle/worker_factory/template.yaml` - Added `provision_worker` skill - `capabilities/_muscle/worker_factory/run.py` - Added `_handle_provision_worker()` for mesh-driven provisioning ### Key Design - **Provisioning** = Factory worker claims `provision_worker` intent, creates worker registration + instance record - **Execution** = Worker claims real intent, mesh spawns process for execution - **Separation of concerns**: Factory registers candidates, mesh handles actual execution lifecycle ### New Test File - `tests/integration/test_phase2_1_provisioning.py` - 17 integration tests (all passing) ### Test Results ``` 17 passed in 1.80s ``` ### What's Working - Factory responds to `provision_worker` intents - Reliability bone enforces idempotency, retries, deadlines - Worker instances tracked in ledger - Router can detect eligible instances - Full loop: boundary.found → provision_worker → factory → ledger → router ### Next: Node Provisioning (#44) - Separate from worker provisioning - Add `unstable.tail018ac4.ts.net` as mesh node - Then workers can be provisioned on that node

Mark referenced this issue

2026-03-16 21:21:22 +00:00

[Phase 2.2] Skills as first-class mesh primitive (tool + guidance + constraints + lifecycle) #45

Mark commented

2026-03-19 03:07:13 +00:00

Author

Owner

Architecture correction note (prevent propagation):

Node != Worker
Mesh node is infrastructure presence/resource envelope
Worker is execution entity that claims intents and does work
Orchestrator is a mesh function riding backplane; not a dedicated supernode

Observed anti-patterns to avoid:

Treating containerized mesh-node count as worker count
Assigning worker-type capabilities (writer, generic) directly to nodes
Introducing dedicated deployment-manager supernode model
Node-level direct intent claiming as the canonical worker path

Validation guidance:

Provisioning success should be measured via worker-registry / lifecycle signals
Not by node container count
Deployment/provision intents should be handled by workers via intent protocol

This comment is to lock terminology and execution model consistency while implementation converges.

Architecture correction note (prevent propagation): - Node != Worker - Mesh node is infrastructure presence/resource envelope - Worker is execution entity that claims intents and does work - Orchestrator is a mesh function riding backplane; not a dedicated supernode Observed anti-patterns to avoid: 1) Treating containerized `mesh-node` count as worker count 2) Assigning worker-type capabilities (`writer`, `generic`) directly to nodes 3) Introducing dedicated `deployment-manager` supernode model 4) Node-level direct intent claiming as the canonical worker path Validation guidance: - Provisioning success should be measured via worker-registry / lifecycle signals - Not by node container count - Deployment/provision intents should be handled by workers via intent protocol This comment is to lock terminology and execution model consistency while implementation converges.

Mark added the

feature-request

label

2026-05-12 23:27:06 +00:00

Mark added the

triage-approved

quickfix

labels

2026-05-18 13:30:18 +00:00

Mark added the

in-progress

label