Milestones
List view
## Outcome An external developer integrates the published GuardStep package into a small application using the documentation, without the maintainer implementing the integration for them. This is a discovery milestone, not a commitment to a list of unvalidated features. It can start after the usable alpha; editor tooling is helpful but not a prerequisite. ## Completion checklist - [ ] Agree on one concrete pilot workflow with an external developer and record expected success and failure behavior. Prefer a document-Q&A application using current capabilities. - [ ] Provide one minimal application example that imports the published package and uses generated TypeScript contracts, with clear input validation and per-invocation capability grants. - [ ] Include a deterministic, keyless test path and an optional documented local-provider path; no paid hosted dependency is required. - [ ] Cover invalid input/output, denied tools, provider failures and exhausted budgets end to end; document the trusted-host boundary. - [ ] Have the external developer follow the setup independently and record their actual results, friction and whether GuardStep helped compared with their existing approach. - [ ] Turn reproduced integration problems into bounded issues; resolve blockers or explicitly record limitations before declaring the pilot complete. ## Boundaries No claim of production readiness, multi-tenant isolation or durable recovery. Streaming, human approval, retries, MCP, mobile clients and a hosted platform are not implicitly in scope; propose them separately only if the pilot demonstrates the need. Implementation issues will be scoped after the pilot is chosen, rather than invented to fill the board. No due date is promised.
No due date## Outcome A developer can edit .guard source, see compiler diagnostics for unsaved changes in an editor, and format files consistently without executing workflow hosts. ## Work in scope - #18: deterministic formatter with write and check-only modes. - #19: minimal language-server diagnostics using the existing compiler. ## Completion checklist - [ ] Formatter handles the current executable grammar, including nested branching and fail; document comment preservation/handling. - [ ] Formatting is idempotent and preserves semantic IR (excluding source-location metadata); invalid files are not partially rewritten. - [ ] Format check mode works in CI, with API and installed-CLI regression coverage. - [ ] Language-server tests cover open, change, close, malformed input, recovery and clearing stale diagnostics. - [ ] Unsaved-buffer diagnostics agree with compiler/CLI messages and source ranges, including multiline ranges. - [ ] At least one editor setup is documented and reproducible by another contributor. - [ ] Package instructions and examples reflect the delivered commands and supported setup. ## Boundaries and sequence Start implementation after the executable syntax/RFC outcome is settled. This work is not a blocker for alpha.2. Do not require completion, rename, hover, a marketplace extension, grammar expansion or a new compiler. Any necessary language/comment-semantics change follows the RFC process. No release version or due date is promised.
No due date•0/2 issues closed## Outcome A new user can install the next experimental npm alpha, run documented workflows (including branching), and get predictable diagnostics and guarded execution. The npm package and GitHub prerelease identify the same version and source commit. ## Baseline reviewed September 9, 2026 main at a4a6915 has the compiler, local runtime, typed contracts, provider adapter, deterministic fixtures and IR v2 branching. npm and the existing GitHub prerelease are still 0.1.0-alpha.1. This is release hardening, not a production-readiness promise. ## Work in scope - #35: reject null String arguments; coordinate with existing PR #46. - #37: reject generated TypeScript name collisions before writing files. - #34: verify the deadline fix already included in PR #52 against all acceptance criteria; avoid duplicate implementation. - #33: correct repository selection in the GitHub release job. - #30, #49, #41: package discoverability, executable README syntax, and an accurate security policy. - #51: record the maintainer's RFC outcome and reconcile proposed/source-preview wording with the already merged branching implementation. The merge does not itself record acceptance. ## Completion checklist - [ ] Resolve and verify the scoped bugs and documentation issues above. - [ ] Reconcile the roadmap and branching/API compatibility documentation; distinguish released behavior from main and future plans. - [ ] Record the RFC review outcome and any outstanding limitations before publishing branching. - [ ] Prepare a reviewed version change with package, lockfile and CLI versions aligned; explain IR v1/v2 compatibility in release notes. - [ ] Pass compiler/type, generated-contract, fixture, release and isolated-package checks; CI passes on supported Node versions and package platforms. - [ ] Verify a fresh consumer can install the release and run both documented examples without a paid API key. - [ ] After separate maintainer approval, publish through trusted publishing and verify npm provenance, the alpha tag, and the matching GitHub prerelease. ## Boundaries No formatter, language server, new type-system features, approval gates, durable execution or hosted service is required. Creating this milestone does not authorize publication. No due date is promised.
No due date•0/8 issues closed