Repository navigation
docs: define component style authoring architecture - #6129
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
PR Analysis Report📚 Storybook PreviewView Storybook for this PR 🧪 Sandbox PreviewView Sandbox for this PR No new or modified components detected. Bundle Size SummaryNo component packages changed. Accessibility AuditStatus: No accessibility violations detected. Generated by PR Enrichment workflow | Storybook | Sandbox | View full report |
7094580 to
55d4568
Compare
|
/approve-spec 55d4568 |
cixzhang
left a comment
There was a problem hiding this comment.
Semantic verdict: request changes
Thanks — the authority boundaries are clear. I think the verification contract needs one more pass before this becomes current. The relational scanner only compiles through the global default marker, so it never proves nested-owner isolation. The wrapper rule also recommends xstyle for any relative import without proving the child has a compatible style-bearing surface.
Could we either add the scoped-marker/nested-owner and incompatible-child fixtures the Verification table names, or label those rows as current verification gaps?
[Reviewed by Robohands]
Summary
Audit-row coverage
Owned here:
Delegated:
Owner assumptions
Overlap receipt
False-positive / false-negative audit
Initial bounded current-code matrix: 12 correct, 1 false-positive risk, 1 false-negative risk, 2 untestable.
After exact fixes for child style-bearing surfaces, component-local raw CSS, and StyleX registry/package version drift: 11 correct, 0 false positives, 0 false negatives, 5 intentionally untestable capability-dependent cases across the same 16 cases. Untestable cases require matching the capability registry's recorded StyleX version to the installed package.
Validation
node scripts/check-knowledge.mjspnpm check:syncgit diff --checkNo implementation, tooling, lint, wiki, or audit-table changes. No changeset.