Skip to content

Echo Execution Bridge Alpha: execute one Edict source fixture on Echo #113

Description

@flyingrobots

Thesis

Push Edict toward Echo execution now, but only as a narrow execution bridge. This is not a general runtime, admission, orchestration, policy, verifier-completeness, or plugin-dispatch slice.

The v0.11 foundation is in place: Edict can compile the supported source subset to Core, lower to canonical echo.span-ir/v1 Target IR, compute canonical Target IR bytes/digests, and assemble participant-neutral bundles from a real TargetIrArtifact. The next product proof is one honest path where Echo consumes that artifact and does one real in-memory operation.

Related Echo work:

Desired path

.edict source fixture
  -> Core
  -> echo.span-ir/v1 Target IR
  -> canonical Target IR bytes + digest
  -> Echo accepts the artifact
  -> Echo executes one in-memory operation
  -> stable execution result/receipt fixture

Scope

  • Add one checked-in .edict source fixture for the supported Echo operation shape.
  • Prove source -> Core -> echo.span-ir/v1 Target IR from executable code, not hand-built prose artifacts.
  • Check canonical Target IR bytes/digest for that fixture.
  • Define the Edict-side handoff artifact that Echo should consume.
  • Coordinate with Echo so the matching Echo issue accepts the artifact, rejects wrong domain/profile/digest/unsupported operation variants, and executes the mapped operation in memory.
  • Record the roadmap adjustment: this execution bridge should land before the current admission-harness milestone, or the admission milestone must be renumbered/rescoped explicitly.

Acceptance criteria

Given a checked-in .edict fixture,
when Edict compiles it,
then it emits canonical echo.span-ir/v1 Target IR with a stable digest.

Given that Target IR artifact,
when Echo validates it,
then Echo accepts the correct artifact and rejects mutated, wrong-profile, wrong-domain, and unsupported-operation variants.

Given the accepted artifact,
when Echo runs the mapped operation against an in-memory store,
then Echo returns a deterministic result or execution receipt tied to the Target IR digest.

Non-goals

  • No general target plugin dispatch.
  • No public edict run unless the internal harness is already deterministic and boring.
  • No full admission policy.
  • No participant identity, delegation, revocation, or Continuum policy engine.
  • No claim of Echo verifier completeness.
  • No arbitrary source-language expansion.
  • No production runtime orchestration.
  • No canonical ContractBundleManifest bytes.

Notes

This should not be smuggled into the admission harness. The current roadmap's planned v0.12 admission harness explicitly excludes runtime execution. This issue is a product-driven bridge between the v0.11 cryptographic artifact foundation and later admission/policy work.

Activity

  1. coderabbitai commented on Jul 1, 2026

    @coderabbitai
    🔗 Related PRs

    #9 - feat(syntax): Phase 1 — Edict lexer + minimal-v1 parser [merged]
    #18 - release: prepare v0.1.0-alpha.1 [merged]
    #41 - Add Gate C admission boundary checks [merged]
    #67 - Add Echo Target IR lowering [merged]
    #110 - Prepare v0.11.0-alpha.1 release [merged]


    📝 Issue Planner

    Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.

    • Create Plan

    🧪 Issue enrichment is currently in open beta.

    You can configure auto-planning by selecting labels in the issue_enrichment configuration.

    To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

    issue_enrichment:
      auto_enrich:
        enabled: false

    💬 Have feedback or questions? Drop into our discord!

  2. flyingrobots commented on Jul 4, 2026

    @flyingrobots
    OwnerAuthor

    Refined by #116.

    The Echo execution bridge should keep terminal obstruction distinct from future preserved repairable obstruction. Current require ... else remains terminal. A future resumable obstruction form needs first-class syntax/Core/Target IR disposition rather than a helper function hidden inside else.

  3. flyingrobots commented on Jul 11, 2026

    @flyingrobots
    OwnerAuthor

    Provider-boundary update: this issue should no longer be read as "make Edict execute on Echo" or as an in-tree Echo coupling plan. The immediate Edict DAG is now #138 with features #139, #140, and #141. That path keeps Edict runtime-neutral: providers supply generated lawpacks/target profiles/authority facts plus lowerer/verifier components; Edict consumes explicit digest-locked provider artifacts and validates envelopes/bindings/bundle identity.

    Once #138 lands, this issue should either be narrowed to an Echo-owned provider proof or superseded by an Echo repo issue for an edict-echo provider implementation.

  4. flyingrobots commented on Jul 13, 2026

    @flyingrobots
    OwnerAuthor

    Superseded by the runtime-owner path now rooted at flyingrobots/echo#650.

    The original objective is not abandoned, but this Edict-owned/in-tree bridge is no longer the correct ownership boundary:

    • Echo #657 owns external-provider parity and the reviewed cross-repo fixture.
    • Echo #583 owns admission and native Echo execution.
    • Echo #516 owns app-safe JS/WASM/browser delivery.
    • Echo #589 remains the final Jedit-on-Edict release gate.

    Edict's generic provider groundwork is complete in #138. Closing this issue as not planned because its repository ownership and in-tree coupling plan were superseded.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestrelease:continuum-stackContinuum stack convergence release workrelease:target-irRelease work for Target IR generationrelease:target-profilesTarget-profile contract and authority source release work

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions