Skip to content

jedit Optic Intent / Observation Handoff #495

Description

@flyingrobots

Migrated from Method backlog

This issue was created from a legacy filesystem backlog card. GitHub Issues are now the live work tracker; repository docs remain Method evidence.

Source backlog: docs/method/backlog/up-next/PLATFORM_jedit-hot-text-runtime-host-surface.md
Original lane: up-next
Original legend: PLATFORM

Original backlog card

jedit Optic Intent / Observation Handoff

  • Lane: up-next
  • Legend: PLATFORM
  • Rank: 1

Why now

jedit now has a real authored GraphQL contract for its hot-text boundary,
including:

  • mutation operations
    • createBufferWorldline
    • replaceRange
    • createCheckpoint
  • a canonical read operation
    • worldlineSnapshot

Wesley can generate TypeScript and Zod operation registries from that
contract, and jedit now consumes those registries in its app-owned adapter.

The next blocker is not in jedit. It is in the substrate handoff model.

Echo's current public wasm/kernel boundary exposes:

  • generic intent ingest
  • generic observation
  • neighborhood publication
  • settlement publication

That is directionally correct, but the integration posture now needs to match
the optic model more explicitly:

  • the application submits intent through an optic-shaped boundary
  • Echo admits or rejects that intent against generic substrate truth
  • Echo records ingress/admission evidence for that intent and later exposes the
    scheduler-owned receipt through observation/correlation
  • the application then observes the resulting worldline state and projects that
    generic graph truth into app-specific nouns

What is missing is not a jedit-named Echo API. What is missing is the first
clean handoff that connects:

  • Wesley-compiled app intents
  • Wesley-compiled observer plans
  • generic Echo intent ingest / deterministic result envelopes
  • generic Echo observation and hosted observer lifecycle
  • app-side projection over observed worldlines

Hill

Define the first substrate handoff that lets a jedit-style application use
Echo through optics without:

  • putting app-specific rewrite names on Echo's generic public API
  • reopening host-authored native rewrite code
  • forcing jedit to fake causal state changes entirely in app-local runtime

Done looks like

  • one Echo-facing design or spec note states the optic handoff explicitly:
    • app submits intent
    • Echo returns ingress/admission evidence and later exposes scheduler-owned
      receipt evidence plus a hologram/frontier handoff
    • app reads through a generic observer plan or observer handle
  • the note explains where app-specific operation names live:
    • authored in the app contract
    • compiled by Wesley
    • encoded into generic substrate intents
    • never promoted to handwritten Echo public methods
  • the note also explains where app-authored observer behavior lives:
    • authored as app observer spec
    • compiled by Wesley into generic observer plans
    • hosted by Echo without handwritten app callbacks
  • one concrete seam is named for the first jedit hot-text operations:
    • create buffer worldline
    • replace range
    • create checkpoint

The authored contract may declare retained tick/receipt obligations for these
operations. That declaration does not let application code create or schedule
ticks.

  • read canonical worldline snapshot

  • repo truth makes clear how those operations travel through:

    • Wesley-generated intent / codec artifacts
    • Wesley-generated observer plan / reading codec artifacts
    • generic Echo intent ingest
    • deterministic receipt / result envelopes
    • generic observation and observer hosting
    • app-side worldline projection

Repo evidence

  • crates/echo-wasm-abi/src/kernel_port.rs
  • crates/warp-wasm/src/lib.rs
  • docs/design/0012-dynamic-footprint-binding-runtime.md
  • docs/invariants/DECLARATIVE-RULE-AUTHORSHIP.md
  • external Continuum optics paper: optics/warp-optic.pdf
  • docs/design/0013-generic-observer-api-and-plan.md

Activity

  1. coderabbitai commented on Jun 1, 2026

    @coderabbitai
    Contributor
    🔗 Related PRs

    #326 - Echo contract hosting roadmap [merged]
    #329 - Stack Witness 0001 fixture-backed jedit walking skeleton [merged]
    #331 - feat(core): add optic invocation admission skeleton [merged]
    #365 - feat(wesley): emit query observer host helpers [merged]
    #368 - feat(core): connect installed contract intent pipeline [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. added and removed on Jun 1, 2026
  3. flyingrobots commented on Aug 18, 2026

    @flyingrobots
    OwnerAuthor

    Architecture supersession note: this issue predates the now-explicit
    Jim.edict active-observer ownership model. Do not use it to add Jedit nouns,
    verbs, rope intrinsics, planners, or callbacks to Echo, or to make a TypeScript
    frontend call application operations directly as the final composition.

    The active generic-runtime work is #684, Interpret compiler-produced bounded
    Edict graph programs
    . It is blocked on flyingrobots/jedit#296 producing a real
    compiler-generated package from Jim-owned ReplaceRange.edict. Jedit's schema
    and oracle are ABI/conformance evidence only, never executable semantic input.
    The final consumer cutover is flyingrobots/jedit#295 and #301: Echo delivers
    canonical events to installed Jim.edict, which requests bounded readings,
    derives Jim-owned operation intents, handles outcomes, and advances editor
    state.

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

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions