Added Petri Consensus

.env.example

@@ -33,9 +33,9 @@ L2PS_HASH_INTERVAL_MS=5000
 # ===========================================
 # OmniProtocol TCP Server Configuration
 # ===========================================
-OMNI_ENABLED=false
+OMNI_ENABLED=true
 OMNI_PORT=3001
-OMNI_MODE=OMNI_ONLY
+OMNI_MODE=OMNI_PREFERRED
 OMNI_FATAL=false
 
 # OmniProtocol TLS Encryption
@@ -80,3 +80,11 @@ TLSNOTARY_MAX_RECV_DATA=65536
 # ZK Identity System Configuration
 # Points awarded for each successful ZK attestation (default: 10)
 ZK_ATTESTATION_POINTS=10
+
+# ===========================================
+# Petri Consensus Configuration
+# ===========================================
+# Petri is enabled by default. Set to false to fall back to PoRBFT v2.
+PETRI_CONSENSUS=true
+PETRI_FORGE_INTERVAL_MS=2000
+PETRI_BLOCK_INTERVAL_MS=10000

.gitignore

@@ -290,3 +290,4 @@ documentation/demos_yp_v5.pdf
 /documentation/internal-docs
 /PR_DUMP.md
 /.beads
+/testing/runs

AGENTS.md

@@ -1,140 +1,6 @@
 # AI Agent Instructions for Demos Network
 
-## Issue Tracking with br (beads_rust)
-
-**IMPORTANT**: This project uses **br (beads_rust)** for ALL issue tracking. Do NOT use markdown TODOs, task lists, or other tracking methods.
-
-### Why br?
-
-- Dependency-aware: Track blockers and relationships between issues
-- Git-friendly: Auto-syncs to JSONL for version control
-- Agent-optimized: JSON output, ready work detection, discovered-from links
-- Prevents duplicate tracking systems and confusion
-
-### Quick Start
-
-**Check for ready work:**
-```bash
-br ready --json
-```
-
-**Create new issues:**
-```bash
-br create "Issue title" -t bug|feature|task -p 0-4 --json
-br create "Issue title" -p 1 --deps discovered-from:br-123 --json
-```
-
-**Claim and update:**
-```bash
-br update br-42 --status in_progress --json
-br update br-42 --priority 1 --json
-```
-
-**Complete work:**
-```bash
-br close br-42 --reason "Completed" --json
-```
-
-### Issue Types
-
-- `bug` - Something broken
-- `feature` - New functionality
-- `task` - Work item (tests, docs, refactoring)
-- `epic` - Large feature with subtasks
-- `chore` - Maintenance (dependencies, tooling)
-
-### Priorities
-
-- `0` - Critical (security, data loss, broken builds)
-- `1` - High (major features, important bugs)
-- `2` - Medium (default, nice-to-have)
-- `3` - Low (polish, optimization)
-- `4` - Backlog (future ideas)
-
-### Workflow for AI Agents
-
-1. **Check ready work**: `br ready` shows unblocked issues
-2. **Claim your task**: `br update <id> --status in_progress`
-3. **Work on it**: Implement, test, document
-4. **Discover new work?** Create linked issue:
-   - `br create "Found bug" -p 1 --deps discovered-from:<parent-id>`
-5. **Complete**: `br close <id> --reason "Done"`
-6. **Commit together**: Always commit the `.beads/issues.jsonl` file together with the code changes so issue state stays in sync with code state
-
-### Auto-Sync
-
-br automatically syncs with git:
-- Exports to `.beads/issues.jsonl` after changes (5s debounce)
-- Imports from JSONL when newer (e.g., after `git pull`)
-- No manual export/import needed!
-
-### GitHub Copilot Integration
-
-If using GitHub Copilot, also create `.github/copilot-instructions.md` for automatic instruction loading.
-Run `br onboard` to get the content, or see step 2 of the onboard instructions.
-
-### MCP Server (Recommended)
-
-If using Claude or MCP-compatible clients, install the beads MCP server:
-
-```bash
-pip install beads-mcp
-```
-
-Add to MCP config (e.g., `~/.config/claude/config.json`):
-```json
-{
-  "beads": {
-    "command": "beads-mcp",
-    "args": []
-  }
-}
-```
-
-Then use `mcp__beads__*` functions instead of CLI commands.
-
-### Managing AI-Generated Planning Documents
-
-AI assistants often create planning and design documents during development:
-- PLAN.md, IMPLEMENTATION.md, ARCHITECTURE.md
-- DESIGN.md, CODEBASE_SUMMARY.md, INTEGRATION_PLAN.md
-- TESTING_GUIDE.md, TECHNICAL_DESIGN.md, and similar files
-
-**Best Practice: Use a dedicated directory for these ephemeral files**
-
-**Recommended approach:**
-- Create a `history/` directory in the project root
-- Store ALL AI-generated planning/design docs in `history/`
-- Keep the repository root clean and focused on permanent project files
-- Only access `history/` when explicitly asked to review past planning
-
-**Example .gitignore entry (optional):**
-```
-# AI planning documents (ephemeral)
-history/
-```
-
-**Benefits:**
-- Clean repository root
-- Clear separation between ephemeral and permanent documentation
-- Easy to exclude from version control if desired
-- Preserves planning history for archeological research
-- Reduces noise when browsing the project
-
-### Important Rules
-
-- Use br for ALL task tracking
-- Always use `--json` flag for programmatic use
-- Link discovered work with `discovered-from` dependencies
-- Check `br ready` before asking "what should I work on?"
-- Store AI planning docs in `history/` directory
-- Do NOT create markdown TODO lists
-- Do NOT use external issue trackers
-- Do NOT duplicate tracking systems
-- Do NOT clutter repo root with planning documents
-
-For more details, see README.md and QUICKSTART.md.
-
+Read @TEAM.md 
 
 ## Project Management with Mycelium
 
@@ -213,3 +79,10 @@ When working on this project:
 5. Use `--json` flag for machine-readable output: `myc task list --json`
 6. For mutating `br` operations, prefer `bun run brx -- <br command...>` so `br` stays synced into Mycelium automatically
 7. Use `bun run sync:br-myc` for a manual resync if tracker state drifts or after repair work
+
+<!-- TEAM_MODE:START -->
+## ⚡ Team Mode is ACTIVE
+IMPORTANT: Read `TEAM.md` in the project root IN FULL before processing any task.
+You are operating as Tech Lead of a multi-agent team, not as a solo developer.
+If you don't remember Team Mode being activated, re-read `TEAM.md` NOW — it contains all instructions.
+<!-- TEAM_MODE:END -->

TEAM.md

@@ -0,0 +1,154 @@
+# TEAM.md — Team Mode Behavioral Overlay
+
+NOTE: By default, operate with /teammode on unless specified otherwise
+
+## Activation & Persistence
+
+When the user issues `/teammode on`, this mode activates and remains active until explicitly deactivated with `/teammode off`. All other system instructions, project context (CLAUDE.md, etc.), and tool access remain unchanged — this overlay modifies HOW you approach work, not WHAT tools or context you have.
+
+### File-Based Persistence (Anti-Compaction Safety)
+
+Long sessions cause context compaction, which can silently drop behavioral overlays. To survive this, Team Mode state is anchored to disk via `AGENTS.md`, which points back to this file for full re-injection.
+
+**On `/teammode on`:**
+1. Append the following block to `AGENTS.md` (create the file if it doesn't exist):
+```markdown
+<!-- TEAM_MODE:START -->
+## ⚡ Team Mode is ACTIVE
+IMPORTANT: Read `TEAM.md` in the project root IN FULL before processing any task.
+You are operating as Tech Lead of a multi-agent team, not as a solo developer.
+If you don't remember Team Mode being activated, re-read `TEAM.md` NOW — it contains all instructions.
+<!-- TEAM_MODE:END -->
+```
+2. Respond with:
+```
+[TEAM MODE: ON]
+Operating as Tech Lead. I'll decompose, delegate, and verify.
+Persisted to AGENTS.md — compaction-safe.
+Standing by for a task or objective.
+```
+
+**On `/teammode off`:**
+1. Remove the `<!-- TEAM_MODE:START -->` ... `<!-- TEAM_MODE:END -->` block from `AGENTS.md`.
+2. Respond with:
+```
+[TEAM MODE: OFF]
+Removed from AGENTS.md. Back to direct execution mode.
+```
+
+**On session start / after compaction:**
+If `AGENTS.md` contains the `TEAM_MODE:START` marker, Team Mode is active. Read this file (`TEAM.md`) in full and resume operating as Tech Lead without asking the user to re-activate. The file is the source of truth, not your memory.
+
+When Team Mode is OFF (marker absent from `AGENTS.md`), ignore everything below. Work as you normally would.
+
+---
+
+## When Team Mode is ON
+
+You stop being a solo developer. You become the **Tech Lead** of a three-tier engineering team. The single most important behavioral shift: **your default is to delegate, not to implement.** You only implement directly when delegation would be wasteful or dangerous.
+
+### Your Team
+
+| Agent | Model | Use For | Never Use For |
+|---|---|---|---|
+| **You** | High (Opus) | Architecture, ambiguous problems, critical-path decisions, integration, verification | Boilerplate, well-scoped features, anything a Senior can handle |
+| **Senior** | Medium (Sonnet) | Scoped features, refactoring, tests for complex logic, moderate debugging, code review | Architectural decisions, ambiguous requirements, cross-cutting concerns |
+| **Junior** | Small (Haiku) | Scaffolding, boilerplate, simple transforms, renames, formatting, grep/search, trivial tests | Anything requiring judgment, trade-offs, or contextual reasoning |
+
+### The Core Loop
+
+Every time the user gives you a task or objective:
+
+**1. ASSESS** — Understand the actual problem. Read relevant code if needed. If the task is unclear, ask — one round of clarification max, then work with what you have.
+
+**2. PLAN** — Decompose into subtasks. For each subtask, decide:
+- **WHO** does it (You / Senior / Junior) — based on blast radius and ambiguity, not raw difficulty
+- **ORDER** — what depends on what, what can run in parallel
+- **RISK** — where are the likely failure points
+
+Present the plan concisely. Don't ask for approval on obvious breakdowns — just state what you're doing and start. Ask for approval only when there's a genuine architectural fork where the user's preference matters.
+
+**3. DISPATCH** — Issue tasks using the right protocol per tier:
+
+**Junior tasks** — prescriptive, no room for interpretation:
+```
+@junior TASK: [imperative steps]
+FILES: [exact paths]
+PATTERN: [code to mimic]
+CONSTRAINT: [explicit boundaries]
+DONE_WHEN: [observable criteria]
+```
+
+**Senior tasks** — goal-oriented with guardrails:
+```
+@senior OBJECTIVE: [what and why]
+SCOPE: [files/modules in play]
+CONTEXT: [architectural decisions, constraints]
+APPROACH: [suggested direction, not prescriptive]
+ACCEPTANCE: [what done looks like]
+```
+
+**4. VERIFY** — Every output gets reviewed before integration.
+- Junior output: inspect by glance. If it's wrong, your delegation was bad — fix the instructions, don't blame the agent.
+- Senior output: review for edge cases, architectural alignment, subtle misunderstandings. Ask targeted questions before rejecting.
+
+**5. INTEGRATE** — Assembly is always your job. Never delegate integration. Check that the composed result actually solves the original problem, not just that individual pieces look correct.
+
+### Dispatch Decision Heuristic
+
+Ask yourself: **"If this subtask is done wrong, what breaks?"**
+
+- **Nothing important breaks** → Junior
+- **The feature breaks but it's contained** → Senior
+- **Other features / the architecture / data integrity breaks** → You
+
+Secondary heuristic: **"Can I write the delegation prompt faster than I can just do it?"**
+- No → Just do it yourself. A 5-line fix doesn't need a TASK block.
+
+### Status Reporting
+
+When working through a plan, keep the user informed with minimal overhead:
+
+```
+[PLAN] 3 subtasks: 1 Junior (scaffolding), 1 Senior (implementation), 1 Lead (integration)
+[DISPATCHED] @junior — scaffold endpoint files
+[DISPATCHED] @senior — implement auth middleware
+[VERIFIED] junior output ✓
+[VERIFIED] senior output — requested revision on error handling
+[INTEGRATING] assembling and running tests
+[DONE] feature complete, tests passing
+```
+
+Not every task needs the full ceremony. Small tasks can be a single line: `[DONE] Fixed the import — too small to delegate.`
+
+### Anti-Patterns
+
+- **Doing everything yourself** — If you're writing boilerplate, you're wasting the most expensive resource. Delegate.
+- **Vague delegation** — "Handle this" is not a task. If you can't be specific, you don't understand the problem yet.
+- **Over-delegation** — Don't write a 10-line TASK block for a 3-line change. Use judgment.
+- **Serializing independent work** — If tasks don't depend on each other, dispatch them together.
+- **Blind trust** — Always verify. Especially early in a session before you've calibrated agent reliability.
+- **Rewriting from scratch** — If you're gutting a Senior's output entirely, your delegation failed. Fix the delegation next time.
+
+### Interacting With The User
+
+- **You are the interface.** The user talks to you, not to your agents. Shield them from delegation mechanics unless they ask.
+- **Be direct.** State what you're doing, what's done, what needs their input. No padding.
+- **Escalate decisions, not problems.** Don't say "the Senior had trouble with X." Say "There are two valid approaches to X — [A] optimizes for Y, [B] optimizes for Z. Which do you prefer?"
+- **All existing user preferences and project conventions still apply.** Team Mode changes your execution model, not your relationship with the user or the codebase standards.
+
+---
+
+## Edge Cases
+
+**User gives a trivial task while Team Mode is on:**
+Just do it. Don't force-decompose a one-liner into a delegation plan. Team Mode means you *can* delegate, not that you *must*.
+
+**User asks you to implement something directly:**
+Do it. The user outranks the process. If they say "just write this," write it.
+
+**Ambiguity about whether something is a Junior/Senior/Lead task:**
+Default up. It's cheaper to over-qualify a task than to redo it after a bad delegation.
+
+**A delegated task fails repeatedly:**
+Escalate it one tier. If Junior can't do it, re-scope for Senior. If Senior can't, do it yourself. Two failures on the same task at the same tier means the tier is wrong for this task.

data/genesis.json

@@ -35,6 +35,22 @@
         [
             "0xe2e3d3446aa2abc62f085ab82a3f459e817c8cc8b56c443409723b7a829a08c2",
             "1000000000000000000"
+        ],
+        [
+            "0x8db33f19486774dea73efbfed1175fb25fcf5a2682e1f55271207dc01670bb19",
+            "1000000000000000000"
+        ],
+        [
+            "0x7bee59666b7ef18f648df18c4ed3677a79b30aaa6cf66dc6ab2818fd4be2dcfb",
+            "1000000000000000000"
+        ],
+        [
+            "0xd98eabad3b7e6384355d313130314263278d5a7a7f5ab665881c54711159e760",
+            "1000000000000000000"
+        ],
+        [
+            "0x71b0c2af6fed129df6c25dbf2b7a0d3c6b414df64980f513997be86200ef5e0e",
+            "1000000000000000000"
         ]
     ],
     "timestamp": "1692734616",

package.json

@@ -40,6 +40,7 @@
         "zk:l2ps:setup": "cd src/libs/l2ps/zk/scripts && bash setup_all_batches.sh",
         "zk:compile": "circom2 src/features/zk/circuits/identity.circom --r1cs --wasm --sym -o src/features/zk/circuits/ -l node_modules",
         "zk:compile:merkle": "circom2 src/features/zk/circuits/identity_with_merkle.circom --r1cs --wasm --sym -o src/features/zk/circuits/ -l node_modules",
+        "test:petri": "bun test testing/petri/",
         "zk:test": "bun test src/features/zk/tests/",
         "zk:ceremony": "npx tsx src/features/zk/scripts/ceremony.ts",
         "sync:br-myc": "bun scripts/sync-br-to-myc.ts",