Skip to content

The Spellweaver

Through motion and silence, the thread remembers its course.

Spellweaver keeps one chosen score through execution, pause, return, and ending. It is LychD's singular logical workflow jurisdiction: it validates immutable Scrolls and admits their casting. Weaver remains the short name used by code and existing paths.

A Scroll is one immutable revision of a Pattern. An Agent call, Gate, tool, effect, wait, or delegation may warrant an independently named Spell; a Scroll-local station places that Spell's exact contract. The score fixes their relationship before work begins.

Future packages may contribute Spell contracts and Scroll declarations through separate Spellweaver-shaped stores. Executable implementations and adapters remain separate Extension or effect-owner registrations; publication and activation are not implied by contribution. The Core office retains workflow authority. Spellweaver never inherits the policy or physical control of the offices it sequences. ADR 28 owns the complete contract.

From Product to performance

A Composition or Suite publishes the score for its work. A Product packages that choice; application records, judgment, and effects remain with their owners.

  • Pattern is one named executable-score lineage published by its application owner: normally a Composition, or a Suite for coordination only; one immutable revision is a Scroll. The two delivered Core Patterns are an explicit retained pre-Portfolio exception.
  • Spell is one independently named semantic action contract; a station places it in that Scroll.
  • Invocation opens one bounded Circle.
  • Casting performs the exact Scroll inside that Invocation.
  • Run is the durable execution and ledger identity of that Invocation.

A Suite Casting opens one parent coordination Invocation/Run from its Suite-owned Scroll and separate child Composition Invocations/Runs. The parent owns correlation and aggregate settlement, never a member's records, judgment, consent, credentials, or effects.

Graph is the typed topology that advances Scroll state among Spell placements. The Loom is a read-only projection of its declared truth. The current fixed registry has no independent Spell catalogue or teaching surface.

The current registry is fixed and source-defined:

bridge_chat@1 (default) / bridge_chat@2 (configured exact capability)
WeaveContext → Converse → AwaitConsent? → ProjectReply → End

bridge_chat@3 (configured public Archive and exact capability)
RecallNotes → AnswerNotes → SettleNoteAnswer → End

bridge_chat@4 (configured Scout and exact local capability)
PreparePageReview → AwaitPageConsent → AcquireAndAnswerPage → SettlePageAnswer → End

bridge_chat@5 (configured semantic generation and exact local capability)
RecallSemanticNotes → AnswerSemanticNotes → SettleSemanticAnswer → End

delegated_rite@1 (default) / delegated_rite@2 (configured exact runtime)
DispatchDelegate ⇢ ProjectDelegatedReply → End

Admission chooses once. The registered workflow name and exact manifest snapshot are committed with the Run; resume looks up that stored choice and never routes the Intent again.

The registry is executable substrate, not a general workflow platform. delegated_rite@1 exercises only the deterministic reference adapter. Revision 2 pins an explicit registered runtime and profile for new admissions and retains that selection across resume. Neither revision supplies foreign-runtime containment or an execution plane.

Choose a Bridge capability

In the Codex's lychd.toml, select the registered Bridge revision and the exact capability key from your declared runtime inventory:

[weaver.bridge]
revision = "2"
capability_key = "my-runtime:chat:my-model"

Replace the example key with your runtime's key. It identifies the Animator, capability family, and model together; a shared model name alone cannot pin a runtime. The selected capability must support chat and tools. Loading Settings validates the selector's shape without contacting an engine; Dispatcher checks the actual declaration, readiness, and policy at execution. An unknown, incompatible, or unavailable target refuses the turn rather than choosing another runtime.

Restarting with this configuration selects revision 2 for new Bridge admissions. The Run stores its choice before queue publication and retains it through hardware retries and consent pauses. Changing or removing the setting does not redirect an existing Run or an idempotent retry. Omitting the section keeps revision 1's eligible-pool selection for new turns. Both revisions stay registered for retained work. This key pins capability identity, not a model artifact or runtime configuration fingerprint; the general Resolution Lock remains a separate contract.

Revision 3 adds bounded public-note recall with transient Context injection and no tools. Its Archive configuration and authority checks are separate from revision 2's tool-capable conversation.

Revision 4 adds one explicitly declared public page, native consent and transient local-model Context. Its Scout configuration selects a qualified static runtime and finite budgets. Neither profile turns a Scroll or source-authored text into tool authority.

Revision 5 adds read-only answers from the independently enabled Archive semantic generation, without tools or earlier conversation history. Its semantic generation configuration binds the exact generation, explicit threshold and finite recall bounds to one exact local Chat capability at boot. The selected Run retains that binding; opening the sources-only recall focus does not change the configured casting.

Prefer a ready route at admission

Revision 2 may instead rank exactly two declared local Chat routes:

[weaver.bridge]
revision = "2"

[weaver.bridge.preference]
schema_version = 1
routes = [
  { capability_key = "local-a:chat:model-a", weight = 9 },
  { capability_key = "local-b:chat:model-b", weight = 1 },
]

Replace both keys with literal identities from the declared inventory. Omit capability_key from [weaver.bridge] when using preference; revision 2 accepts exactly one of them. Both routes, including a disabled one, must declare local Soulstone Chat with tool support. Revisions 3, 4 and 5 retain their exact-key configuration and reject preference.

Weights are integer preferences from 0 through 1,000,000, with a positive total; they are not traffic percentages, measured quality, or additional authority. Zero disables eligibility and omits that route's retained phase and observation time. Admission directly refreshes each Animator hosting an enabled route once, as a complete Animator batch, within one cooperative five-second bound. That batch may include a disabled capability sharing the same Animator. After the batch, only observed-warm routes with unchanged declarations and an unchanged, open admission generation remain eligible. Highest weight wins; an equal weight uses ascending literal capability key. This observes readiness without activating a model, preparing a grant or entering inference. Malformed or failed probes abort admission; a valid non-warm observation excludes that route. An empty eligible set returns a content-free 503 code before retaining a Run or user turn.

The Run retains the complete policy, its digest, dated observations and one exact selected key. An idempotent replay returns that retained decision before any new probe. Configuration changes apply only to new admissions. Execution and restart keep the selected key under the existing Bridge tools, consent and retry rules; later unavailability may pause or refuse execution. The batch does not reserve future readiness, and it supplies no execution fallback.

The selected Run's Orb inspector shows these retained observations and exclusions. They describe admission time, not current availability. Follow configured Bridge casting for the qualification boundary and Dispatcher law for the selection and execution distinction.

Follow the Scroll

Choose the route that matches the question:

  • Discovery and router delegation follows scope branches, makes nested routes and workflows discoverable, and carries the selected routes into a bounded task handoff.
  • Pattern lifecycle covers identity, manifests, admission, contribution, authorship protection, and revision continuity.
  • Crucible covers two-round adversarial formation: declared biased Postures, independent first claims, attributed rebuttal, dissent-preserving synthesis, and the Magus Gate.
  • Creation applies bounded Inquiry at direction and construction scales, turns support and measure into bounded next steps, and follows local or delegated task handoffs through verification, documentation and authorized VCS effects.
  • Ouroboros connects work, evaluation and training through correction, memory, Assimilation, Packaging and Evolution.
  • Development bootstrap carries an operator-controlled coding campaign through evidence gates toward bounded native delegation and spare-capacity work. Coding-runtime research compares the dated provider roads behind that procedure.
  • Scheduling and service classes covers foreground, deadline-windowed, and spare-capacity admission, schedule time law, overlap, and explicit misses.
  • Stasis and return covers Live and Durable Stasis, checkpoints, re-admission, terminal cleanup, and recovery limits.
  • Execution roads covers the layered choice among native/local work, Portal-backed cognition, sovereign A2A tasks, delegated coding runtimes, and operator seats.
  • Anonymization, taint, and egress covers the local Privacy Cut, information-flow labels, Portal admission, quarantined return, and the boundary that makes subsidized remote reasoning usable.
  • Delegated agents covers the typed delegated station, AgentJob boundary, future CLI adapter acceptance, containment, and the present deterministic, no-network, effect-free reference adapter.

Creation and its interpretation

Transmutation in Divination examines the Sephiroth correspondence: the relations that give an idea form, symmetry and reconstruction, and life and the ending of forms. Creation and Ouroboros keep the practical procedures here in Spellweaver, with handoffs to evaluation and learning.

Progressive craft without a mutable score

A Scroll may admit several explicit finish boundaries. A completed intermediate artifact can begin a new forward Invocation; a terminal Run is never reopened to continue it. Pattern lifecycle distinguishes new input from a changed score.

Model and engine choice stays in the receiver-owned Resolution Lock. A Comfy graph is an implementation preset, and a portable A2A Scroll remains inert until admitted. Follow Composition Suites when the work needs live coordination across application owners.

Hand off a bounded task

In the scoped context handoff, the coordinating Agent keeps the wider purpose while another Agent receives a fresh Context for one task. For a repository change, that packet gives the requested result, relevant operator decisions, acceptance checks, allowed paths, source revision, dependencies, and a scope routing to the owning documents and code. The recipient reads those owners without inheriting the whole conversation that led to the task.

If a needed decision is missing, the recipient requests that bounded input. It returns a candidate patch or findings with verification evidence and unresolved questions for the coordinator to assess. Merely loading another scope in the same conversation does not perform this handoff.

The present score

State of Work records local execution and the separate Stasis, delegation, extension, and Loom delivery boundaries. Pattern contribution and durable publication, scheduling, durable parallelism, compatibility and migration, editing, authorship attestation, and protected-region admission remain undelivered.

Repository coding-agent choreography is separate: the tracked workflow playbooks own contributor procedure only, never Spellweaver or Pattern law.