registrystack / registrystack/registry-stack

Epic: First-class editor support for Registry Stack project authoring

Aperta
#399 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub
area:registryctl criticality:p3 enhancement post-1.0 triage:roadmap
Lingua principale
Rust
Stelle
2
Fork
0
Merge medio
2h 55m
PR unite (30g)
130

Descrizione

## Outcome

Registry Stack project YAML has first-class editing support in VS Code and Zed, beginning with a schema-driven 1.0 demo baseline and growing into one shared semantic language server. The editor packages remain thin and do not duplicate the project compiler, security rules, or released Rhai/CEL surface.

## Release plan

### 1.0: useful demo baseline

- [x] #394

The 1.0 scope uses the five existing project-authoring JSON Schemas with the editors' normal YAML language servers. It delivers validation, completion, hover documentation, and outlining without waiting for custom semantic tooling.

### 1.2: shared semantic tooling

- [x] #396
- [x] #401
- [x] #393
- [ ] #395
- [ ] #397
- [ ] #398

## Dependency order

```text
#394 schema-driven baseline (1.0)

#396 structured diagnostics and editor metadata
#401 span-preserving authoring YAML parsing
-> #393 shared Registry Stack language server
-> #395 VS Code extension
-> #397 Zed extension
-> #398 references, safe rename, and embedded Rhai/CEL assistance
```

#396 and #401 can proceed in parallel; #393 depends on both. The VS Code and Zed packaging issues can proceed in parallel once the shared language-server contract and MVP are stable.

## Design constraints

- Use the exact schemas, diagnostics, and expression metadata from the selected Registry Stack or `registryctl` release.
- Do not bind editor behavior to a mutable branch or silently mix incompatible versions.
- Preserve normal YAML editing and avoid claiming unrelated YAML files.
- Keep the compiler's trust-boundary checks, bounded paths, and secret handling intact.
- Do not read secret values, execute project scripts, perform live tests, or make source-registry network requests as a side effect of editing.
- Share semantic behavior through LSP instead of implementing it separately in VS Code and Zed.
- Verify a clean developer journey in both editors, separately from protocol and security tests.

## Success criteria

- [ ] A 1.0 demo project gets useful schema-driven editing in VS Code and Zed through a short deterministic setup.
- [ ] Cross-file paths and project-local references navigate correctly through the shared LSP.
- [ ] Invalid syntax and semantic references produce precise, structured diagnostics.
- [ ] Both editor integrations use the same language server and version compatibility contract.
- [ ] Published extension installation, binary discovery, troubleshooting, and release ownership are documented.
- [ ] Advanced rename and expression support never executes authored code or weakens project validation.

Guida per i contributori

Apri la guida per i contributori

Direzione di ricerca

Leggi il piano di rilascio e la catena delle dipendenze, in particolare #393, #395, #397 e #398, quindi esamina i cinque JSON Schemas esistenti di project-authoring e la configurazione standard di YAML language-server descritta per 1.0. Il lavoro è completato quando sia VS Code sia Zed utilizzano gli strumenti condivisi e compatibili con la versione, con un’editing utile, diagnostica precisa, navigazione sicura dei riferimenti e installazione e risoluzione dei problemi documentate.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Valutazione

Stack tecnologico
rust, vscode, yaml
Ambito
developer-experience, devtools, tooling
Tipo di issue
Funzionalità
Difficoltà
5/5
Tempo stimato
Più di una settimana
Stato di attività
Tranquilla
Chiarezza
Abbastanza chiara
Idoneità per principianti
25/100

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.