idea34-openpassmarket-privacy-preserving/AGENTS.md

AGENTS: OpenPassMarket Core - Architecture & Contribution Guide

Overview

• This repository hosts the core primitives for a privacy-preserving federated optimization marketplace prototype.
• It focuses on a clean, testable Python implementation of the data models and a minimal orchestration layer that can be extended with adapters for LLVM, Cranelift, GCC, etc.

Tech Stack

• Language: Python 3.8+
• Packaging: pyproject.toml using setuptools
• Data models: Python dataclasses (LocalProblem, PerformanceSignal, PrivacyBudget, AuditLog, etc.)
• Registry: GraphOfContracts (in-memory registry for adapters and contract versions)
• Tests: pytest

Testing & Running

• To run tests: bash test.sh
• Packaging build: python3 -m build

Repository Rules for Agents

• Do not modify user-facing behavior abruptly; aim for small, well-scoped changes with clear tests.
• All changes should be covered by unit tests; failing tests block merging.
• Documentation: update AGENTS.md and README.md when introducing new modules or public APIs.
• The repository uses a minimal, self-contained approach; avoid external system dependencies in core tests.

Contribution Workflow

• Implement small, focused changes first (data models, simple utilities).
• Add/extend tests to cover the new behavior.
• Update README and AGENTS.md to reflect new APIs and usage.

Note

• This is a seed for a larger ecosystem; subsequent iterations will add REST/IPC adapters, TLS transport, and a conformance/test harness.

OpenPassMarket MVP Skeleton (Phase 0) Improvements

• Purpose: Provide a production-ready, Python-based core prototype with a canonical data model and minimal orchestration to bootstrap adapters for LLVM, Cranelift, GCC, etc.
• Focus areas (Phase 0):
• Canonical contract data model: PassSpec, LocalProblem, PerformanceSignal, PrivacyBudget, AuditLog, GraphOfContracts, PlanDelta.
• Lightweight adapters: two starter adapters (LLVM pass fixture and a dummy benchmark) to demonstrate interoperability with the canonical IR.
• Transport: TLS-based (REST or gRPC) transport skeleton for secure communications between adapters and the registry/orchestrator.
• Verifier: compact IR invariants checker ensuring transforms preserve basic properties and respect privacy budgets.
• Delta-sync: deterministic offline backtests with cryptographic attestations for reproducibility.
• Governance ledger: append-only log scaffold for adapter approvals, policy updates, and contract/version changes.
• What to implement next (high level):
• 1. Extend the Graph-of-Contracts registry with discovery and conformance checks.
• 2. Implement two toy adapters and a tiny orchestrator that sequences passes within a privacy budget.
• 3. Add a minimal conformance test harness for adapters.
• 4. Provide simple delta-sync replay tooling for offline tests.
• 5. Update README with a marketing description and developer onboarding notes.