#114 - Capabilities should be refactored into skill bundles - not autonomous entities - Mark/mesh-seed - cyguin git: Adlerian Hierarchical Self-Actualization Syllogism

Mark commented

2026-04-10 19:40:11 +00:00

Owner

Architecture Violation

Capabilities are currently treated as autonomous entities throughout the codebase - they have backplane access, emit signals, subscribe to channels. This violates the fundamental architecture principle.

Correct Architecture

Per AGENTS.md and docs/primitives.md:

Capabilities are skill bundles attached to workers
Workers use skills to execute work
Skills do NOT execute themselves
Capabilities are templates, not runtime entities

Current Incorrect Behavior

Evidence of capability-as-entity violations:

Capabilities access backplane directly
Capabilities emit signals (e.g., result.committed)
Capabilities subscribe to channels
Capability templates treated as active participants in mesh flow

Required Fix

Refactor all capability code to be:

Templates only - YAML definitions of skill bundles
No backplane access - Workers subscribe, not capabilities
No signal emission - Workers emit results, not capabilities
Passive metadata - Capability templates describe worker behavior

Impact

This is foundational to the architecture. Without this fix:

Factory pattern cannot work correctly
Worker spawning remains broken
Routing remains confused
All downstream architecture fixes blocked

References

AGENTS.md - Architecture principles
docs/primitives.md - Capability definition
docs/reference/FACTORY_PATTERN.md - Factory/capability relationship
capabilities/_muscle/worker_factory/run.py - Shows capability-as-entity pattern

## Architecture Violation Capabilities are currently treated as autonomous entities throughout the codebase - they have backplane access, emit signals, subscribe to channels. This violates the fundamental architecture principle. ## Correct Architecture Per AGENTS.md and docs/primitives.md: - **Capabilities are skill bundles attached to workers** - **Workers use skills to execute work** - **Skills do NOT execute themselves** - **Capabilities are templates, not runtime entities** ## Current Incorrect Behavior Evidence of capability-as-entity violations: - Capabilities access backplane directly - Capabilities emit signals (e.g., `result.committed`) - Capabilities subscribe to channels - Capability templates treated as active participants in mesh flow ## Required Fix Refactor all capability code to be: 1. **Templates only** - YAML definitions of skill bundles 2. **No backplane access** - Workers subscribe, not capabilities 3. **No signal emission** - Workers emit results, not capabilities 4. **Passive metadata** - Capability templates describe worker behavior ## Impact This is foundational to the architecture. Without this fix: - Factory pattern cannot work correctly - Worker spawning remains broken - Routing remains confused - All downstream architecture fixes blocked ## References - AGENTS.md - Architecture principles - docs/primitives.md - Capability definition - docs/reference/FACTORY_PATTERN.md - Factory/capability relationship - capabilities/_muscle/worker_factory/run.py - Shows capability-as-entity pattern

Mark commented

2026-04-10 20:15:31 +00:00

Author

Owner

Clarification on Correct Architecture

After discussion, the correct model is clearer:

Capabilities = Intent Contract Definitions

Capabilities should define the contract being bid upon:

Intent type they handle (e.g., write_article)
Input schema - What the intent payload must contain
Output schema - What the result must return
Skill family - Which skills can fulfill (abstract, not specific skill)

Workers Bid on Intent Types via Capabilities

# capability contract template
intent_type: write_article
skill_family: writer
input_schema:
  - topic: string (required)
  - format: string (optional)
  - word_count: int (optional)
output_schema:
  - content: string (required)
  - word_count: int (actual)

Workers advertise which capabilities they have. When an intent arrives, workers with matching capabilities bid. The capability is the contract/interface definition.

Implementation Still Worker-Centric

Workers load capability template to understand what they're bidding on
Workers use skills from the skill_family to execute
Workers emit results that match output_schema
Capabilities are passive metadata, not active participants

What This Means for Refactoring

Capability templates remain (define contracts)
Remove backplane access from capability code
Remove signal emission from capability code
Workers read capability templates to understand intent contracts
Workers bid, execute, emit - capabilities just define the interface

This aligns with AGENTS.md routing section on Contract-Intent Binding and docs/primitives.md.

## Clarification on Correct Architecture After discussion, the correct model is clearer: **Capabilities = Intent Contract Definitions** Capabilities should define the contract being bid upon: - **Intent type** they handle (e.g., `write_article`) - **Input schema** - What the intent payload must contain - **Output schema** - What the result must return - **Skill family** - Which skills can fulfill (abstract, not specific skill) **Workers Bid on Intent Types via Capabilities** ```yaml # capability contract template intent_type: write_article skill_family: writer input_schema: - topic: string (required) - format: string (optional) - word_count: int (optional) output_schema: - content: string (required) - word_count: int (actual) ``` Workers advertise which capabilities they have. When an intent arrives, workers with matching capabilities bid. The capability is the contract/interface definition. **Implementation Still Worker-Centric** - Workers load capability template to understand what they're bidding on - Workers use skills from the skill_family to execute - Workers emit results that match output_schema - Capabilities are passive metadata, not active participants **What This Means for Refactoring** 1. Capability templates remain (define contracts) 2. Remove backplane access from capability code 3. Remove signal emission from capability code 4. Workers read capability templates to understand intent contracts 5. Workers bid, execute, emit - capabilities just define the interface This aligns with AGENTS.md routing section on Contract-Intent Binding and docs/primitives.md.

Mark commented

2026-04-10 21:21:02 +00:00

Author

Owner

Contract as New Primitive - Actualized Intent on Ledger

Building on the clarification above, I propose introducing Contract as a distinct primitive:

Current Intent Model (Fuzzy)

IntentRecord:
  intent_id: str
  status: str  # pending, claimed, completed
  budget: dict
  payload: dict
  claimed_by: str | None
  result: dict | None

Intents are fuzzy requests without formal validation schemas.

Contract Primitive (Actualized Intent)

ContractRecord:
  contract_id: str
  intent_id: str  # Reference to original intent
  intent_type: str  # What kind of work
  
  # Formal interface definition
  input_schema: dict  # Validation rules for payload
  output_schema: dict  # Validation rules for result
  
  # Economic terms
  bond_required: float
  reward_pool: float
  timeout_ms: int
  
  # Skill binding
  skill_family: str  # Which skills can fulfill
  skill_constraints: dict  # Version, performance requirements
  
  # Ledger tracking
  status: str  # proposed, signed, executing, fulfilled, breached
  signatures: list  # Worker signatures committing to contract
  bond_escrow: dict  # escrowed bonds per signer
  
  # Validation
  input_validated: bool
  output_validated: bool
  validation_errors: list

Flow: Intent → Contract → Execution

1. Intent arrives (fuzzy request)
   "write_article about Trump Peace Deal"

2. Contract created on ledger (actualized intent)
   - Validates input against input_schema
   - Defines formal expectations (output_schema)
   - Sets economic terms (bond, reward, timeout)
   - Specifies skill_family requirement

3. Workers bid on contracts
   - Read contract definition
   - Verify they have skill_family
   - Sign contract (commitment)
   - Escrow bond

4. Worker executes
   - Uses skills from skill_family
   - Produces output matching output_schema
   - Ledger validates output

5. Contract fulfilled
   - Output validated
   - Bond released + reward
   - Contract status: fulfilled

Why This Helps

Intents are fuzzy - Contracts make them concrete
Validation is ledger-based - Contract schemas validate at commitment, not ad-hoc
Smart contract semantics - Actualized intent = committed transaction
Worker clarity - Workers see formal expectations, not fuzzy requests
Infrastructure role - Ledger creates contracts, workers bid on them

Implementation Path

Add ContractRecord to ledger schema
Create contract templates in capabilities/_contracts/
Intent → Contract creation on ledger
Workers bid on contracts (not intents directly)
Contract validation bones for input/output

This aligns with smart contract patterns - the contract IS the actualized intent, defining the transaction terms before execution.

## Contract as New Primitive - Actualized Intent on Ledger Building on the clarification above, I propose introducing **Contract** as a distinct primitive: **Current Intent Model (Fuzzy)** ```python IntentRecord: intent_id: str status: str # pending, claimed, completed budget: dict payload: dict claimed_by: str | None result: dict | None ``` Intents are fuzzy requests without formal validation schemas. **Contract Primitive (Actualized Intent)** ```yaml ContractRecord: contract_id: str intent_id: str # Reference to original intent intent_type: str # What kind of work # Formal interface definition input_schema: dict # Validation rules for payload output_schema: dict # Validation rules for result # Economic terms bond_required: float reward_pool: float timeout_ms: int # Skill binding skill_family: str # Which skills can fulfill skill_constraints: dict # Version, performance requirements # Ledger tracking status: str # proposed, signed, executing, fulfilled, breached signatures: list # Worker signatures committing to contract bond_escrow: dict # escrowed bonds per signer # Validation input_validated: bool output_validated: bool validation_errors: list ``` **Flow: Intent → Contract → Execution** ``` 1. Intent arrives (fuzzy request) "write_article about Trump Peace Deal" 2. Contract created on ledger (actualized intent) - Validates input against input_schema - Defines formal expectations (output_schema) - Sets economic terms (bond, reward, timeout) - Specifies skill_family requirement 3. Workers bid on contracts - Read contract definition - Verify they have skill_family - Sign contract (commitment) - Escrow bond 4. Worker executes - Uses skills from skill_family - Produces output matching output_schema - Ledger validates output 5. Contract fulfilled - Output validated - Bond released + reward - Contract status: fulfilled ``` **Why This Helps** 1. **Intents are fuzzy** - Contracts make them concrete 2. **Validation is ledger-based** - Contract schemas validate at commitment, not ad-hoc 3. **Smart contract semantics** - Actualized intent = committed transaction 4. **Worker clarity** - Workers see formal expectations, not fuzzy requests 5. **Infrastructure role** - Ledger creates contracts, workers bid on them **Implementation Path** 1. Add `ContractRecord` to ledger schema 2. Create contract templates in `capabilities/_contracts/` 3. Intent → Contract creation on ledger 4. Workers bid on contracts (not intents directly) 5. Contract validation bones for input/output This aligns with smart contract patterns - the contract IS the actualized intent, defining the transaction terms before execution.

Mark referenced this issue

2026-04-10 22:04:11 +00:00

Terminology: template.yaml files are CONTRACT templates, not capability templates #117

Mark commented

2026-04-10 22:06:21 +00:00

Author

Owner

Complete Architecture Flow (Based on User Clarification)

Correct Terminology:

Intent = fuzzy request arriving at intake
Contract = actualized intent (formal interface on ledger)
Capability = skill bundle attached to worker
Worker = execution context (spawned AFTER bid wins)

Complete Flow:

1. INTAKE: Intent arrives
   "write_article about Trump Peace Deal"
   ↓
   
2. INTAKE → CONTRACT: Infrastructure creates contract on ledger
   - Validates input against input_schema
   - Defines formal interface (input/output)
   - Sets economic terms (bond, reward, timeout)
   - Creates ContractRecord on ledger
   ↓
   
3. PROXY BIDDING: Mesh substrate arbitrates
   - Infrastructure handles bidding (NOT workers)
   - Workers don't exist at bidding phase
   - Proxy bids based on contract requirements
   - Winning bid selected
   ↓
   
4. WORKER SPAWN: Winning bid spawns worker
   - Worker created with contract reference
   - Worker loads skill bundle (capability)
   - Worker has contract_id + skills
   ↓
   
5. EXECUTION: Worker executes contract
   - Reads contract definition
   - Uses skills from skill_family
   - Produces output matching output_schema
   ↓
   
6. VALIDATION: Ledger validates output
   - Check output against contract.output_schema
   - Validate constraints (word count, citations)
   - Mark contract as fulfilled/breached
   ↓
   
7. REWARD/SLASH: Economic resolution
   - Output validated → bond released + reward
   - Output failed → bond slashed
   - Contract status: fulfilled or breached

Key Invariants:

Intake creates contracts - Not workers, not manual process
template.yaml = contract templates - Interface definitions, not worker attributes
Workers don't bid - Proxy bidding by mesh substrate, workers spawned after win
Contract on ledger - Actualized intent with formal validation schemas
Worker has contracts + skills - Workers reference contracts, load skills

Current Code Violations:

Every place the code says "capability" it means one of three different things:

Contract template (template.yaml)
Contract reference (worker.capabilities field)
Skill bundle (worker.skills field)

This is a three-way terminology collision causing systemic confusion.

References

User clarification: "Intake generates contracts because they are intents"
User clarification: "template.yaml are contract templates, never were capability templates"
User clarification: "Workers don't exist at bidding phase. Proxy bids are arbitrated through mesh substrate"

## Complete Architecture Flow (Based on User Clarification) **Correct Terminology:** - Intent = fuzzy request arriving at intake - Contract = actualized intent (formal interface on ledger) - Capability = skill bundle attached to worker - Worker = execution context (spawned AFTER bid wins) **Complete Flow:** ``` 1. INTAKE: Intent arrives "write_article about Trump Peace Deal" ↓ 2. INTAKE → CONTRACT: Infrastructure creates contract on ledger - Validates input against input_schema - Defines formal interface (input/output) - Sets economic terms (bond, reward, timeout) - Creates ContractRecord on ledger ↓ 3. PROXY BIDDING: Mesh substrate arbitrates - Infrastructure handles bidding (NOT workers) - Workers don't exist at bidding phase - Proxy bids based on contract requirements - Winning bid selected ↓ 4. WORKER SPAWN: Winning bid spawns worker - Worker created with contract reference - Worker loads skill bundle (capability) - Worker has contract_id + skills ↓ 5. EXECUTION: Worker executes contract - Reads contract definition - Uses skills from skill_family - Produces output matching output_schema ↓ 6. VALIDATION: Ledger validates output - Check output against contract.output_schema - Validate constraints (word count, citations) - Mark contract as fulfilled/breached ↓ 7. REWARD/SLASH: Economic resolution - Output validated → bond released + reward - Output failed → bond slashed - Contract status: fulfilled or breached ``` **Key Invariants:** 1. **Intake creates contracts** - Not workers, not manual process 2. **template.yaml = contract templates** - Interface definitions, not worker attributes 3. **Workers don't bid** - Proxy bidding by mesh substrate, workers spawned after win 4. **Contract on ledger** - Actualized intent with formal validation schemas 5. **Worker has contracts + skills** - Workers reference contracts, load skills **Current Code Violations:** Every place the code says "capability" it means one of three different things: - Contract template (template.yaml) - Contract reference (worker.capabilities field) - Skill bundle (worker.skills field) This is a three-way terminology collision causing systemic confusion. ## References - User clarification: "Intake generates contracts because they are intents" - User clarification: "template.yaml are contract templates, never were capability templates" - User clarification: "Workers don't exist at bidding phase. Proxy bids are arbitrated through mesh substrate"

Mark referenced this issue

2026-04-11 02:26:12 +00:00

CRITICAL: No vector/semantic embedding infrastructure for bidding #123

Mark referenced this issue from a commit

2026-04-19 16:33:53 +00:00

Architecture fixes: worker handoff, starvation signals, bootstrap recovery

Mark added the

blocked:commit-ready-failed

label

2026-05-13 00:20:38 +00:00

Mark added

blocked:needs-decision

and removed

blocked:commit-ready-failed

labels

2026-05-15 21:00:02 +00:00

Mark commented

2026-05-15 22:38:45 +00:00

Author

Owner

Ops Pipeline — BLOCKED

Research could not determine a clear ops procedure.

[subagent-0] ⚠️ Unknown tool 'grep' — sending error to model for self-correction (1/3)
Now I have a complete picture. Here's the full analysis:

HOST: localhost (~/Projects/mesh-seed/)

STATUS: BLOCKED

EVIDENCE: Comprehensive codebase analysis confirms Issue #114's violation claim is accurate. Two clear violations and one derivative violation exist. The remaining 25+ capabilities under primitives/_muscle/ and primitives/_nerve/ correctly follow the passive template/skill-bundle pattern.

## Ops Pipeline — BLOCKED Research could not determine a clear ops procedure. [subagent-0] ⚠️ Unknown tool 'grep' — sending error to model for self-correction (1/3) Now I have a complete picture. Here's the full analysis: --- HOST: localhost (~/Projects/mesh-seed/) STATUS: BLOCKED EVIDENCE: Comprehensive codebase analysis confirms Issue #114's violation claim is accurate. Two clear violations and one derivative violation exist. The remaining 25+ capabilities under primitives/_muscle/ and primitives/_nerve/ correctly follow the passive template/skill-bundle pattern.

Mark removed the

blocked:needs-decision

label

2026-05-15 22:40:00 +00:00

Mark added the

triage-approved

bug

quickfix

labels

2026-05-17 22:58:03 +00:00

Mark added the

in-progress

label

2026-05-27 17:23:15 +00:00

Mark commented

2026-05-27 17:29:02 +00:00

Author

Owner

🤖 [quickfix-mesh-seed-114] still working — overseer retry