Roadmap & contribution opportunities

[zenithruneblade]

A contribution map for the whole LychD project: core maintainers, the founder and independent contributors. Milestones express integrated outcomes, not a promise that one small team implements everything or that other work must wait.

Current / Next / Later

Horizon	Integrated outcome	Sequencing focus
Current	Local installation	#1 and #2 establish typed configuration plus the guarded CLI/layout journey; #3 and #18 realize and operate the host topology; #4 and #47 close inspection and persistence evidence.
Next	First local conversation	#5 and #6 provide the agent/model boundary; #7 dispatches one exact capability; #8 executes the first Run; #10 and #11 project it through the Altar.
Later	Local multimodal	#21, #23 and #42 admit the extension/artifact/capability surfaces; #48 and #49 deliver audio/vision slices; #50 integrates the local multimodal outcome with #36 correlation.

This ordering identifies the shortest integrated proof. It does not block independent contract, fixture, documentation, or extension work.

Current sequencing focus

1. Configuration — Pydantic Settings & Runic TOML #1 — typed Settings and Rune configuration.
2. CLI — init, layout & removal #2 — guarded initialization, layout, removal, and CLI proof.
3. Bind — Quadlet generation & systemd binding #3 — compiled Quadlet/systemd binding.
4. Lifecycle — start, readiness, stop & restart #18 — lifecycle and readiness.
5. Status — installation & unit checks #4 plus Persistence — core SQL models, migrations and async transactions #47 — operator inspection and persistent migration evidence.

Delivery path

Outcome	Issues
Local installation	#2 / #1 → #3 → #18; inspect with #4 and verify persistence with #47
First local conversation	#5 + #6 → #7 → #8; #10 + #8 → #11
Local multimodal	#21 / #23 / #42 → #48 + #49 → #50, with #36 correlation
Deeper runtime policy	#16 resource policy and #17 ranking/fallback after the first integrated evidence

These are completion paths. Interfaces, fixtures, adapters and documentation can be contributed in parallel.

Cross-cutting master maps

• Extension Master — all extensibility surfaces and child-issue map #63 maps the complete extension surface and routes registration, providers, Scrolls, persistence, packaging and evolution without becoming another architecture source.
• Configuration Master — Settings, Runes, selectors and generation boundaries #64 maps configurable surfaces, precedence and immutable generation transitions without turning configuration into code, readiness or authority.
• Extensions — manifest, dependency locks, migrations and safe lifecycle #65 is the bounded extension manifest/dependency-lock/migration lifecycle slice below Extension Master — all extensibility surfaces and child-issue map #63.
• CLI Master — host-owned command surface and operator journeys #71 maps the host-owned CLI command surface; Dispatch Master — eligibility, ranking, grants and redispatch #72 maps Dispatcher eligibility, ranking, grants, and redispatch.
• Advanced execution — architecture and evidence review #62 remains the advanced execution architecture/evidence review; Graph — nested subgraphs & bounded parallel execution #61 remains the bounded nested/parallel Graph topology.

From application purpose to execution

Question	Route
Who owns the durable records, judgment, finish and recovery?	Start with the Composition Portfolio and Choosing a Home. Portfolio membership is Designed application truth, not executable delivery.
What exact score may run?	A Composition publishes a Pattern lineage; one immutable revision is a Scroll. #29 introduces the first public Spell/Scroll registration and persisted Resolution Lock under Spellweaver.
How is a software change prepared?	#40 is the SDLC/Creation path from immutable request to verified candidate and inert promotion request. #35 Smith/Assimilation adds foreign-source provenance, licence and quarantine; neither path promotes itself.
Where are advanced interactions reviewed?	#62 is the finite Orchestration Master review/decomposition tracker. It coordinates evidence without becoming another runtime component or blocking the first local and multimodal paths.

New executable application Patterns require an exact Composition owner, or a Suite owner for coordination only. YAML may later be an authoring projection compiled to canonical typed JSON; it is neither application ownership nor executable identity.

Explore by area

Area	Entry points
Host, configuration and persistence	#1–#4, #18, #47; restore #44, package #45, update rehearsal #46
Runtime and extensions	#5–#8, #16/#17, #21/#22/#29/#42; modalities #48–#50
Altar	#9 collects #10–#15 and #56 settings
Authority, execution and privacy	#23–#28, #37/#38; each effectful feature owns its boundary tests
Knowledge, evaluation and creation	#30–#34; #35 Smith/Assimilation, #39 Inquiry/Crucible, #40 SDLC/Creation and #41 Shadow
Remote work and acquisition	#19 A2A, #20 Tether, #55 Portal, #57 Veil, #43/#51 Scout
Observation and contributor tooling	#36 Oculus, #53 isolated development, #54 templates (completed), #58 docs clarity

Choose a contribution

Working branches: task branches and fork PRs target dev; a tested snapshot advances to main. Reviews are requested where useful and maintainers may self-merge. Full issue acceptance plus promotion to main means Done. CONTRIBUTING owns the procedure.

• help wanted: an explicit contribution entry is available; some require deep experience. good first issue: a small prepared newcomer task. Comment with the piece you want to take; partial PRs are welcome.
• needs-design: use the issue's Open decision to propose a bounded implementation contract under its ADR. It does not mean architecture is absent or only paid maintainers may contribute.
• Blocked by: a missing result prevents final acceptance. It does not prohibit independent contract/fixture work. Sub-issue: a real piece of the parent's deliverable. Other links coordinate interfaces.
• A milestone groups an intended outcome; unmilestoned work is welcome. Ready means the named next contribution has agreed scope and verification; closing its issue still requires the full checklist. Assignees reflect accepted responsibility, not employment.
• Keep each PR independently reviewable. Parents and integration issues close only when their full acceptance is demonstrated. Record canonical decisions in the repo; Discord participation is optional.

Documentation is part of completion

Every feature PR updates the owning docs and stale delivery claims it changes, removes filler/repetition from that touched prose, and checks links plus the relevant documentation gates. Preserve intentional myth, humour, canonical terms and exact security/recovery meaning. #58 covers a finite entrypoint pass; it is not a global gate or substitute for feature-owned docs.

Later direction — pointers, not implementation commitments

• Legion / owned nodes: ADR 42, after explicit node authority, Intercom and local resource-admission evidence. A2A is not already a fleet.
• Separate Gateway Home/Remote: Gateway, after an admitted Veil profile and its network boundary.
• Advanced orchestration review: Advanced execution — architecture and evidence review #62 maps concurrent Intents, durable waits, execution roads, A2A/Tether, privacy, recovery and their Altar evidence. It is a review/decomposition tracker, not a prerequisite for earlier delivery.
• Nested subgraphs and parallel Graph: Graph — nested subgraphs & bounded parallel execution #61, after Orchestration — multi-model switching & resource policy #16/Dispatch — configurable ranking & bounded fallback #17 runtime policy and Workers & Ghouls — durable service jobs and recovery #22 durable service waits; proposals and fixtures can start earlier.
• Streaming/full-duplex media and long-lived services: follow Echo — local record-and-send speech through Graph #48/Vision / Prism — one image-grounded conversation #49/Scrolls / Workflow — register and run one revision-pinned Scroll #29/Capabilities — admit one typed non-model service #42 when their first receipts expose the next useful contract.
• Adaptive placement, real training, autonomous evolution and production payments: follow Orchestration — multi-model switching & resource policy #16/Dispatch — configurable ranking & bounded fallback #17/Soulforge / Training — admitted dataset and trainer handoff #34/Evolution — rehearse an update and its recovery path #46/Toll — accounting contracts and an x402 adapter seam #32; no speculative deep checklist here.

Sources of truth

State of Work owns delivered capability; ADRs own architecture; CONTRIBUTING owns setup and checks. This index routes work and does not duplicate their claims.