chore: 40 - Define the capability record schema

[Exohayvan]

Roadmap step

phase-1/step-40: Step 40 - Define the capability record schema

Objective

Complete the selected roadmap step using only the programmatically selected step details.

Selected step

# Step 40 - Define the capability record schema

## Source Checklist Item
- [ ] Define the capability record schema.

## Goal
Define a small, explicit capability record schema that lets a local AetherMesh node advertise what it can honestly do, how that claim was produced, and how another local component can validate it. The schema should preserve creator node ID, manifest references, validation receipts, lineage, and contribution attribution without implying production decentralization or unsupported network behavior.

## Implementation Checklist
- [ ] Create a capability record schema for local prototype use only.
- [ ] Include stable identifiers: capability ID, creator node ID, schema version, created timestamp, and updated timestamp.
- [ ] Include capability metadata: name, description, capability type, supported input formats, supported output formats, constraints, and local execution requirements.
- [ ] Include manifest references for the node, runtime, model, tool, or worker that backs the capability.
- [ ] Include validation fields: validation status, validation receipt IDs, last validated timestamp, validation command or check name, and failure reason when applicable.
- [ ] Include lineage fields linking the capability to its source manifest, prior capability record, or local build artifact when relevant.
- [ ] Include contribution attribution fields for the creator, maintainer, and any local work receipts produced through the capability.
- [ ] Document required fields, optional fields, allowed enum values, and example valid records.

## Required Tests Or Verification
- [ ] Validate a complete example capability record against the schema.
- [ ] Validate that missing creator node ID, manifest reference, or validation status fails.
- [ ] Validate that unknown capability types or malformed receipt references fail.
- [ ] Confirm the schema can represent an unvalidated capability without presenting it as trusted.

## Risks
- [ ] Capability records may overstate what a node can do if validation fields are optional or vague.
- [ ] Schema drift may break later routing if identifiers and lineage are not stable.
- [ ] Attribution may be lost if contribution fields are treated as display-only metadata.

## Done When
- [ ] The capability record schema is documented with required fields, enums, and examples.
- [ ] Local validation can accept a valid record and reject incomplete or dishonest records.
- [ ] The schema preserves node identity, manifests, validation receipts, lineage, and attribution.

Changes

3d53c8a chore: complete phase-1 step-40
 docs/capability-record-schema.md         |  55 ++++++++
 examples/local-capability-record.json    |  37 +++++
 src/aethermesh_core/capability_record.py | 229 +++++++++++++++++++++++++++++++
 tests/test_capability_record.py          | 118 ++++++++++++++++
 4 files changed, 439 insertions(+)

Validation

• PYTHONDONTWRITEBYTECODE=1 python scripts/full_test.py --mode fast --base origin/main --keep-going

Safety notes

• Roadmap selection was performed by the Python loop, not by the AI agent.
• No force push used.
• No hard reset used.
• Local automation paths are intentionally omitted.

[Exohayvan]

Automated review marked this PR fixable on the final allowed pass and pushed fixes. The loop is leaving it open for another review cycle instead of closing repaired work.

[Exohayvan]

Automated review marked this fixable, but no safe fix was produced. Closing as not approved.

[Exohayvan]

Closed by Python AetherMesh loop: fixable review produced no safe changes.