Planning documents are non-normative. Use them for roadmap context, design rationale, and measured evidence, not as the source of language or CLI truth.
Current authority order:
../spec/RSScript_v0.7_Spec.mdfor language syntax and semantics.../spec/RSScript_Execution_Spec_v0.1.mdfor VM/JIT execution contracts.../../README.mdandrss --helpfor implemented user-facing commands.- The active planning docs below.
The package-manager design doc is still versioned v0.6. Treat it as design
background unless a claim also matches the root README, rss --help, or current
tests.
| Doc | Use it for |
|---|---|
spec-todo.md |
Current v0.7 implementation backlog and explicitly removed non-goals. |
vm-optimizing-jit-plan.md |
Current VM/JIT optimization state, shipped slices, and remaining perf work. |
jit-production-readiness-plan.md |
Phased plan to promote the native JIT to the production execution tier (findings register F1–F11, phases P0–P4). |
dev-build-test-speed-plan.md |
Proposed developer-loop speed work. |
refactor-plan.md |
Proposed behavior-preserving module decomposition. |
declarative-rewrite-roadmap.md |
Design path for graph rewrite / tinygrad-style scheduler work. |
ml-perf-todo.md |
ML framework performance follow-ups. |
cross-isolate-design.md |
Message-channel contract status and remaining true-isolate design. |
These files are intentionally kept because they record measurements, rejected approaches, or design rationale that should not be rediscovered. They are not the current roadmap unless an active doc above links to them as the source for a specific claim.
| Doc | Status |
|---|---|
RSScript_AI_Generation_Feedback_v0.1.md |
Final design spec for an AI generation feedback loop; implementation planning reference. |
When a plan ships, update its status line and either keep it in "Active Roadmaps" only if more work remains, or move it to "Evidence And Historical Notes". When a feature changes language semantics, update the spec first and make the plan point back to the spec instead of restating the rule.