Merge branch 'main' into claude/enhance-vibe-aaa-standard-ATSCg

Signed-off-by: Jonathan D.A. Jewell <6759885+hyperpolymath@users.noreply.github.com>

Author: hyperpolymath

.machine_readable/6a2/STATE.a2ml

@@ -124,6 +124,7 @@ entries = [
   { date = "2026-04-04", description = "Containerfile updated: all 96 cartridge FFI builds (was 18). Dynamic discovery loop replaces hardcoded list. entrypoint.sh builds LD_LIBRARY_PATH dynamically at startup. 96/96 cartridges now loadable in container." },
   { date = "2026-04-12", description = "V-lang sweep complete (commits c4674f8/cb00882/325b42e/9186016): 0 .v adapter files remain, all 90 cartridges have cartridge.json + mod.js + Zig three-protocol adapter. CI fixes: lcb-website (SHA updates, RSR path migration 6scm→6a2, peter-evans→gh workflow run) + nafa-app (Deno SHA pin, TS exclusion for Deno test files). believe_me sweep: 31→4 across 6 ABI safety modules (commit d262256) — added fromLteTrue (constructive), charEqSound/unpackLength (axiomatic primitives), eliminated all Safety/SafeWebSocket/SafePromptInjection/SafeCORS/SafeAPIKey non-axiomatic instances." },
   { date = "2026-04-17", description = "Spec bump v0.4.0: V-lang ban documented in all spec docs. Cartridge manifest format confirmed as Nickel (closed DD), JSON→Nickel migration tracked as future work. BoJ-only MCP rule added to FEDERATION.md. Unified-zig-api stack alignment documented in ARCHITECTURE.md and ABI-FFI-README.md as planned future work (BoJ does not yet consume libzig_api). ADR-0002 created. EXPLAINME.adoc manifest.json→cartridge.json corrected. META.a2ml languages updated (v removed, zig-adapter noted)." },
+  { date = "2026-04-20", description = "Fix disconnected state: (1) Updated .gemini/settings.json to use 'deno run -A' for MCP bridge (prevents interactive permission prompts). (2) Started Elixir REST backend on port 7700 as Class 3 Multiplier replacement for banned V-lang adapter. (3) Fixed 'just doctor' in Justfile to handle 'zig version' syntax and robust tool detection." },
 ]
 
 [launch-status]

.machine_readable/contractiles/bust/Bustfile.a2ml

@@ -0,0 +1,28 @@
+// Bustfile.a2ml — meta-repo bust contractile (breakage / rollback)
+// SPDX-License-Identifier: PMPL-1.0-or-later
+
+Bust {
+    name: "boj-server"
+    version: "1.0.0"
+    description: "Rollback procedures when something breaks in the meta-repo"
+
+    scenarios: {
+        "bad-pointer-bump": "git revert <bump-commit> in meta-repo; child repo itself untouched"
+        "submodule-pointer-points-at-missing-sha": "git submodule update --init --checkout <path> resets child to parent-recorded SHA; OR revert the stale bump commit"
+        "submodule-orphan-after-local-only-commit": "roll back locally with git reset to before the stranded commit; fix remote situation before re-attempting"
+        "accidental-private-repo-content-leaked-to-public-submodule": "hard-rotate the leaked secret immediately; git-filter-repo or BFG on the submodule's own history; public re-publication only after rotation complete"
+    }
+
+    escalation-ladder: [
+        "1. revert the meta-repo commit (reversible, low blast radius)",
+        "2. reset the local submodule clone (affects only local workspace)",
+        "3. force-push to main — PROHIBITED without explicit user confirmation (violates branch protection)",
+        "4. registry-level (delete/archive the GitHub repo) — human-only action, never by AI"
+    ]
+
+    backup-points: [
+        "GitHub serves as the durable backup for every submodule's own history",
+        "Meta-repo history on origin/main is the durable backup for pointer state",
+        "Local backup tags (backup/pre-<operation>-<date>) retained on risky rewrites"
+    ]
+}

.machine_readable/contractiles/bust/bust.ncl

@@ -0,0 +1,66 @@
+# SPDX-License-Identifier: PMPL-1.0-or-later
+# Bust — error-handling / failure-recovery runner
+#
+# Pairs with: Bustfile.a2ml (same directory)
+# Verb:       bust
+# Semantics:  every declared failure mode must have a recovery path that has
+#             been exercised. Runner injects failures (via declared probes)
+#             and verifies the recovery path works. Hard gate on any
+#             failure-mode with missing or broken recovery.
+# CLI:        `contractile bust check`  → list failure modes + recovery status
+#             `contractile bust drill`  → inject declared failures, verify recovery
+#
+# Anything else in this directory is human-only notes/archive; machines ignore.
+#
+# Base: ../_base.ncl provides pedigree_schema, run_defaults, probe_schema.
+# See: docs/CONTRACTILE-SPEC.adoc
+
+let base = import "../_base.ncl" in
+
+{
+  pedigree = base.pedigree_schema & {
+    contractile_verb = "bust",
+    semantics = "error handling + failure recovery",
+    security = {
+      leash = 'Kennel,
+      trust_level = "controlled failure injection; scoped to system-under-test",
+      allow_network = false,
+      allow_filesystem_write = true,      # drills may write transient state (tmp dirs, test DBs)
+      allow_subprocess = true,
+      injection_scope = "system-under-test-only",
+    },
+    metadata = {
+      name = "bust-runner",
+      version = "1.0.0",
+      description = "Exercises declared failure modes and verifies recovery paths. Hard-gates on any failure mode without working recovery.",
+      paired_xfile = "Bustfile.a2ml",
+      author = "Jonathan D.A. Jewell <j.d.a.jewell@open.ac.uk>",
+    },
+  },
+
+  schema = {
+    failure_modes
+      | Array {
+          id | String,
+          description | String,
+          class | [| 'network, 'disk_full, 'oom, 'timeout, 'partial_write, 'panic, 'crash, 'rollback, 'concurrency |],
+          # TODO: migrate to base.probe_schema (structured probe) when CLI supports it
+          injection_probe | String,          # command that deterministically causes this failure
+          # TODO: migrate to base.probe_schema (structured probe) when CLI supports it
+          recovery_probe | String,           # command that verifies recovery (exit 0 = recovered)
+          expected_recovery_time_seconds | Number | default = 30,
+          # status_core values: 'declared, 'verified, 'failing; bust adds 'drilled
+          status | [| 'declared, 'drilled, 'verified, 'failing |] | default = 'declared,
+          notes | String | optional,
+        },
+  },
+
+  # Runner behaviour — inherits from base.run_defaults.
+  # bust adds record_recovery_times for performance tier feeding.
+  run = base.run_defaults & {
+    on_any_fail = "exit-nonzero",         # missing or broken recovery blocks merge
+    report_format = "a2ml",
+    emit_summary = true,
+    record_recovery_times = true,         # feeds the performance tier
+  },
+}

BOJ_LOGIC.adoc

@@ -0,0 +1,159 @@
+# Bundle of Joy (BoJ) Server: Logic and Architecture
+
+## Overview
+
+The Bundle of Joy (BoJ) server is a unified MCP (Model Context Protocol) server designed to provide a comprehensive suite of tools and capabilities for developers, researchers, and organizations. It is built on a modular architecture that emphasizes flexibility, scalability, and extensibility.
+
+## Core Logic
+
+### Modular Design
+
+The BoJ server is structured around the concept of "cartridges," which are pluggable modules that provide specific functionalities. Each cartridge is isolated and can be loaded or unloaded dynamically without affecting the rest of the system. This design allows for:
+
+- **Isolation**: Each cartridge operates independently, reducing the risk of conflicts or cascading failures.
+- **Extensibility**: New functionalities can be added by creating new cartridges without modifying the core system.
+- **Maintainability**: Cartridges can be updated or replaced individually, simplifying maintenance and upgrades.
+
+### Three-Layer Architecture
+
+The BoJ server employs a three-layer architecture to ensure robustness and flexibility:
+
+1. **ABI Layer (Idris2)**: This layer defines the abstract interfaces and types used by the system. It ensures type safety and provides a clear contract for the rest of the system.
+2. **FFI Layer (Zig)**: This layer implements the foreign function interface, providing high-performance bindings between the ABI layer and the adapter layer.
+3. **Adapter Layer (Zig)**: This layer contains the actual implementations of the tools and functionalities provided by the cartridges.
+
+### Federation and Communication
+
+The BoJ server supports federation through the Umoja protocol, which enables multiple BoJ instances to communicate and collaborate. Key features of the federation include:
+
+- **QUIC Transport**: Encrypted, low-latency communication between nodes.
+- **UDP Fallback**: Ensures compatibility with networks that do not support QUIC.
+- **Gossip Protocol**: Automatic peer discovery and network formation.
+- **Hash Attestation**: Cryptographic verification of nodes to ensure trust and security.
+
+### Knowledge Graph
+
+The BoJ server includes a knowledge graph that stores and manages contextual data about entities such as people, projects, organizations, and tools. The knowledge graph supports:
+
+- **Entities**: Representations of real-world objects with attributes and metadata.
+- **Observations**: Factual statements about entities, with temporal validity and confidence scores.
+- **Relations**: Typed relationships between entities, with weights indicating the strength of the relationship.
+
+### Session Management
+
+The BoJ server provides robust session management capabilities, allowing users to:
+
+- **Persistent Sessions**: Maintain session state across restarts.
+- **Context Loading**: Automatically load context from previous sessions.
+- **Multi-Project Isolation**: Isolate sessions by project to avoid conflicts and ensure data integrity.
+
+### Decision Tracking
+
+The BoJ server includes a structured decision tracking system that records:
+
+- **Title**: A brief description of the decision.
+- **Decision**: The choice made.
+- **Reasoning**: The rationale behind the decision.
+- **Alternatives**: Other options that were considered.
+- **Confidence**: A score indicating the certainty of the decision.
+
+### Learning System
+
+The BoJ server features a learning system that captures and organizes knowledge and insights. Learnings are categorized into types such as:
+
+- **Pattern**: Recurring successful approaches.
+- **Mistake**: Lessons learned from failures.
+- **Insight**: Strategic realizations.
+- **Research**: External knowledge and findings.
+- **Architecture**: System design decisions.
+
+## Technical Implementation
+
+### Language and Tools
+
+The BoJ server is primarily implemented in Zig, with additional components in Idris2 for the ABI layer and TypeScript for the MCP bridge. Key tools and technologies include:
+
+- **Zig**: Used for the FFI and adapter layers due to its performance, memory safety, and interoperability.
+- **Idris2**: Used for the ABI layer to ensure type safety and correctness.
+- **TypeScript**: Used for the MCP bridge to facilitate communication with MCP clients.
+- **SQLite**: Used for local storage of session data, learnings, decisions, and the knowledge graph.
+- **Neo4j**: Used for advanced graph queries and analysis in the knowledge graph.
+
+### Build System
+
+The BoJ server uses the Zig build system for compiling and linking the various components. The build system is configured to:
+
+- Compile the Idris2 ABI layer.
+- Build the Zig FFI and adapter layers.
+- Link the components into a single executable.
+- Manage dependencies and external libraries.
+
+### Testing
+
+The BoJ server includes a comprehensive test suite that covers:
+
+- Unit tests for individual components.
+- Integration tests for cartridge interactions.
+- End-to-end tests for the entire system.
+- Performance benchmarks to ensure scalability and efficiency.
+
+### Documentation
+
+The BoJ server is thoroughly documented, with:
+
+- Asciidoc files for user and developer documentation.
+- JSON Schema definitions for cartridge metadata and tool interfaces.
+- API documentation for the REST, GraphQL, and gRPC endpoints.
+- Examples and tutorials for common use cases.
+
+## Use Cases
+
+### Software Development
+
+The BoJ server can be used to:
+
+- Manage software projects and repositories.
+- Automate build, test, and deployment processes.
+- Track issues, pull requests, and code reviews.
+- Analyze code quality and detect code smells.
+
+### Research and Analysis
+
+The BoJ server can be used to:
+
+- Conduct academic and market research.
+- Analyze datasets and trends.
+- Store and retrieve research findings and insights.
+- Collaborate with other researchers and organizations.
+
+### Communication and Notification
+
+The BoJ server can be used to:
+
+- Send notifications via email, SMS, Slack, Discord, and Telegram.
+- Broadcast messages to multiple channels.
+- Manage communication workflows and alerts.
+
+### Cloud and Infrastructure Management
+
+The BoJ server can be used to:
+
+- Deploy and manage cloud resources on AWS, GCP, Azure, Cloudflare, and Vercel.
+- Monitor and observe infrastructure metrics and logs.
+- Automate infrastructure as code (IaC) processes.
+
+## Future Directions
+
+The BoJ server is continuously evolving, with planned enhancements including:
+
+- **AI Agents**: Autonomous agent orchestration and management.
+- **Workflow Engine**: Visual workflow builder for complex processes.
+- **Marketplace**: Cartridge discovery and installation platform.
+- **Analytics**: Usage metrics and insights for performance optimization.
+- **WASM Cartridges**: WebAssembly-based cartridges for enhanced portability and security.
+- **Blockchain**: Smart contract integration for decentralized applications.
+- **Quantum**: Quantum computing interfaces for advanced research and analysis.
+
+## Conclusion
+
+The Bundle of Joy (BoJ) server is a powerful, modular, and extensible platform designed to meet the diverse needs of developers, researchers, and organizations. Its robust architecture, comprehensive feature set, and commitment to continuous improvement make it a valuable tool for a wide range of applications.