idkmesh

Phase 0 Completion and Next Step

Date: 2026-08-28

Context

After a repository audit identified the gap between IDKMesh’s research/specification layer and an executable foundation, the project owner asked to proceed.

During the implementation check, the repository had already advanced concurrently: the Phase 0 schemas, fixtures, harness, documentation, and CI workflow had landed on main. Rather than duplicate those changes, this turn verified the actual repository state and checked the GitHub Actions result.

Verified Phase 0 artifacts

• schemas/work-unit-v0.1.schema.json
• schemas/experiment-manifest-v0.1.schema.json
• schemas/experiment-result-v0.1.schema.json
• examples/work-units/phase0-smoke.work-unit.json
• examples/experiments/phase0-smoke.manifest.json
• experiments/harness.py
• requirements-phase0.txt
• docs/research/PHASE_0_SPEC.md
• .github/workflows/phase0-schema-check.yml

Verification evidence

GitHub Actions run 33175735121 for commit a2836a8301ee4fa0f77117582650df84b4be8b90 completed successfully.

The CI path validates all Phase 0 schemas and fixtures and runs only the built-in deterministic smoke runner. It does not execute manifest-provided command or external runners.

Tracker update

Issue #19, Phase 0: Implement Work Unit + experiment schemas and reproducible harness, is complete and its checklist/completion evidence was updated.

Important boundary

Phase 0’s Experiment Result is an experiment-run record. It should not silently become the final worker ResultManifest contract.

The worker/coordinator/verifier boundary needs to describe:

• produced candidate artifacts;
• worker environment and tool provenance;
• logs and execution metadata;
• confidence/calibration where useful;
• evidence expected by an independent verifier;
• separation between worker self-report and independent verification evidence.

This distinction preserves the IDKMesh principle that worker success is not acceptance.

Follow-up implemented in the same turn: Worker ResultManifest v0.1

To prevent Phase 1 from being blocked on an ambiguous worker-output contract, the following artifacts were added:

• schemas/result-manifest-v0.1.schema.json
• examples/results/phase0-smoke.result-manifest.json
• examples/results/invalid-self-acceptance.result-manifest.json
• docs/specifications/RESULT_MANIFEST_V0_1.md

experiments/harness.py was extended so validation now checks the valid worker ResultManifest, verifies that it refers to a Work Unit in the manifest with the correct version, verifies that requested evidence artifact ids actually exist, and requires the deliberately invalid self-acceptance fixture to fail.

The invalid fixture adds a top-level accepted: true. Because the worker ResultManifest schema is strict and intentionally contains no acceptance field, CI rejects it. This turns the principle worker success is not acceptance into an executable invariant.

GitHub Actions run 33178414803 completed successfully with these changes.

Issue #3 remains open deliberately until a real worker/orchestrator/validator path exercises the contract. The project should learn from actual integration friction before declaring the schema final.

Repository-health repair discovered during this turn

A concurrent community-growth change had introduced .github/workflows/ace-community-growth.yml, but every push produced an immediate failed Actions run with zero jobs. Inspection showed that JavaScript multiline template-literal continuation lines had escaped the YAML script: | indentation, making the workflow invalid before a job could start.

The workflow was repaired by:

• replacing unsafe multiline template-literal layout with arrays joined by \n;
• keeping every JavaScript line safely inside the YAML block scalar;
• pinning actions/github-script to the stable v7 action;
• preserving the security rule that pull_request_target never checks out or executes pull-request code.

Commit d221ece47ff502d2c78b130015847d7bc8493e3c triggered ACE Actions run 33178589799, which completed successfully. The job update-growth-ledger and all three job steps passed.

This matters because a self-growing repository should not trade community automation for permanently red CI or unsafe execution semantics.

Next execution focus

The project should now move from infrastructure smoke testing to the smallest real local verified-swarm loop:

1. exercise and refine the worker ResultManifest through #3;
2. implement the single-machine multi-worker orchestrator in #4;
3. implement the independent validator/benchmark layer in #5;
4. integrate those pieces into the v0.1 Verified Swarm Runner in #16;
5. test interoperability mapping in #17 without requiring networking for the local v0.1 path.

The next milestone should produce real bounded candidate patches plus independent verification evidence, not another high-level architecture layer.

This site is open source. Improve this page.