V1 readiness scorecard
This scorecard is the public view of Simurgh’s progress toward a stable 1.0.0. A dimension is
ready only when its automated gates pass and its required human evidence is recorded. In
progress means useful evidence exists but at least one published exit criterion remains open.
Blocked means the release cannot advance until the named prerequisite is completed.
Last assessed: 2026-08-20. Overall status: in progress.
Scorecard
Section titled “Scorecard”| Dimension | Status | Evidence today | Remaining exit criteria | Owner |
|---|---|---|---|---|
| Architecture | Ready | Framework packages expose component subpaths; adapter-boundary checks prove every generated framework subpath remains independent of its root barrel, and bundle budgets enforce narrow imports. | Keep adapter boundaries and bundle budgets required for catalog changes. | Framework maintainers |
| Framework parity | Ready | The generated parity matrix fails CI for missing implementations, exports, styles, documentation, or contract coverage across React, Vue, and Angular. | Keep the parity gate required for every catalog change. | Framework maintainers |
| Accessibility | In progress | Contract, axe, keyboard, RTL, form, focus, contrast, and Android/iOS browser smoke coverage exercise representative components. | Record physical-device TalkBack and VoiceOver sessions plus zoom, forced-colors, reduced-motion, touch-target, and focus-appearance observations. | Accessibility reviewers |
| Compatibility | Ready | The compatibility workflow exercises the oldest and newest supported React, Vue, and Angular peers; SSR, hydration, portal, lazy-overlay, and deferred-content contracts are covered. | Keep both compatibility edges and SSR contracts required. | Release engineering |
| Documentation | In progress | Component pages include installation, real previews, API and styling contracts, accessibility guidance, verification markers, and framework-specific feedback links; the automated docs-only journey passes. | Record a consented final task-based user session using only the published documentation. | Documentation maintainers |
| Package integrity | Ready | Packed-package checks validate contents, type resolution, installation, exports, starter production builds, bundle budgets, and package metadata. The nine-package beta registry evidence records exact tags, tarballs, and integrity hashes. | Keep tarball and registry verification required for every release. | Package maintainers |
| Governance | Ready | LICENSE, SECURITY, CONTRIBUTING, CODE_OF_CONDUCT, CODEOWNERS, versioning, support, deprecation, copied-source stability, and breaking-change policies are present and validated. | Keep governance and stability checks required. | Project maintainers |
| Release automation | In progress | Changesets produces package-scoped notes and beta tags; all nine betas were directly published and verified in artifacts/published-beta-evidence.json. | Replace the invalid GitHub NPM_TOKEN or configure npm trusted publishing, then record a successful provenance-bearing CI publish. | Release engineering |
Update policy
Section titled “Update policy”Review the scorecard in every release-candidate pull request and whenever a linked gate changes. Status promotions require a repository link, CI run, or recorded human observation that satisfies the remaining criterion. Regressions move a dimension back immediately; they are not deferred to the next release review.
Before declaring 1.0.0, every row must be ready, all P0 and P1 roadmap work must be closed or
explicitly deferred with rationale, a beta must be published, and beta feedback must be reviewed.
The repository todo.md remains the
detailed work queue; this page is the concise release decision record.
Current V1 blockers
Section titled “Current V1 blockers”The beta publication requirement is complete. The remaining evidence cannot be inferred from automated tests: it requires consented first-time-user icon and release-candidate sessions, physical Android TalkBack and iOS VoiceOver observations, the five documented manual accessibility checks, and review of any issues those sessions discover. Stable versioning remains blocked until those records pass their repository validators. CI publication also needs repaired npm credentials before the first stable release so npm can attach build provenance.
Last verified on 2026-08-13 against Simurgh registry 0.1.1.