{"_id":"@canonical/design-system","_rev":"22-5d2f741113d09958a3bdcff63b7469d9","name":"@canonical/design-system","dist-tags":{"latest":"0.43.0","experimental":"0.43.0-experimental.1"},"versions":{"0.1.0":{"name":"@canonical/design-system","version":"0.1.0","license":"LGPL-3.0","_id":"@canonical/design-system@0.1.0","maintainers":[{"name":"frankban","email":"frankban@gmail.com"},{"name":"huwshimi","email":"huw@ikmail.com"},{"name":"anthonydillon","email":"me@anthonydillon.com"},{"name":"steverydz","email":"steverydz@gmail.com"},{"name":"amylily1011","email":"amy.lily@canonical.com"},{"name":"bartaz","email":"bartek.szopka@canonical.com"},{"name":"jpmartinspt","email":"joao.figueiredo.martins@canonical.com"},{"name":"petesfrench","email":"peterfrench94@gmail.com"},{"name":"jmuzina","email":"jmuzina@pm.me"},{"name":"mtruj","email":"mariapaula.trujillo@canonical.com"},{"name":"edlerd","email":"david.edler@canonical.com"},{"name":"lukewh","email":"luke@lukewh.com"},{"name":"canonical-organization","email":"is-admin@canonical.com"},{"name":"edisile-canonical","email":"eduard.manta@canonical.com"},{"name":"steciuk-canonical","email":"adam.steciuk@canonical.com"},{"name":"akbarik","email":"kz.akbar@gmail.com"},{"name":"ad.vl","email":"adrian.villa.g@gmail.com"},{"name":"engr-ali","email":"its.muhammad.ali.mughal@gmail.com"},{"name":"ando.gq","email":"tom@ando.sh"},{"name":"ninfa_jeon","email":"urvashi.sharma271099@gmail.com"},{"name":"ndv99","email":"n.devilliers1999@gmail.com"},{"name":"alimot1","email":"alimot.akinbode@canonical.com"},{"name":"goulin-canonical","email":"goulin.khoge@canonical.com"},{"name":"immortalcodes","email":"21112002mj@gmail.com"},{"name":"alvaromateo","email":"alvaro.mateoalvarez@canonical.com"},{"name":"onibenjo-canonical","email":"benjaminaderopo.oni@canonical.com"}],"bin":{"collect-implementations":"src/collect-implementations.ts"},"dist":{"shasum":"0f8611201fb49663dad1298aeea9164da55b98c5","tarball":"https://registry.npmjs.org/@canonical/design-system/-/design-system-0.1.0.tgz","fileCount":231,"integrity":"sha512-6y814ZPl5X2vimAGOzMSYpXObwt9/8+0bqTd14RD8VRnta1MBfFlU3EEq0kelpFJsJOqJTkXJaPw7XEFYPT6Dw==","signatures":[{"sig":"MEUCIQDkosAXpllkbC16BZp/0cr+CaknP4istkTFPl1BOhBvEgIgX5NeYBY07f26fTB8q5yZJYffJkuNsCOFxUGzL92WDDc=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"unpackedSize":793715},"type":"module","types":"src/index.ts","module":"index.ts","gitHead":"e1a0bf367f09477fd28e8c88f115940db02752f4","scripts":{"test":"bun run test:vitest","build":"bun run ds:extract && bun run ds:transform","check":"bun run check:biome","ds:list":"bun src/cli.ts list source.json","check:ts":"tsc --noEmit","check:fix":"bun run check:biome:fix && bun run check:ts","ds:extract":"bun src/cli.ts extract source.json","check:biome":"biome check","test:vitest":"vitest run","ds:transform":"bun src/cli.ts transform source.json","check:biome:fix":"biome check --write","test:vitest:watch":"vitest","generate:coda-types":"openapi-typescript https://coda.io/apis/v1/openapi.json -o src/providers/CodaProvider.types.generated.ts"},"_npmUser":{"name":"ad.vl","email":"adrian.villa.g@gmail.com"},"_npmVersion":"10.8.2","description":"An OWL ontology for modeling UI design systems as structured, queryable knowledge graphs. Built to bridge the gap between design specifications and implementation by establishing a shared semantic vocabulary for components, patterns, layouts, and their re","directories":{},"_nodeVersion":"22.8.0","dependencies":{"n3":"^1.26.0","ajv":"^8.17.1","jsonld":"^9.0.0"},"_hasShrinkwrap":false,"devDependencies":{"vitest":"^4.0.15","@types/n3":"^1.26.1","@types/bun":"latest","@types/jsonld":"^1.5.15","@biomejs/biome":"^2.3.8","openapi-typescript":"^7.10.1","vite-tsconfig-paths":"^5.1.4","@canonical/biome-config":"^0.10.0-experimental.4","@canonical/typescript-config-react":"^0.10.0-experimental.4"},"_npmOperationalInternal":{"tmp":"tmp/design-system_0.1.0_1768931993301_0.7649796875147599","host":"s3://npm-registry-packages-npm-production"}},"0.1.1":{"name":"@canonical/design-system","version":"0.1.1","license":"LGPL-3.0","_id":"@canonical/design-system@0.1.1","maintainers":[{"name":"ilayda21","email":"ilayda.cavusoglupars@canonical.com"},{"name":"frankban","email":"frankban@gmail.com"},{"name":"huwshimi","email":"huw@ikmail.com"},{"name":"anthonydillon","email":"me@anthonydillon.com"},{"name":"steverydz","email":"steverydz@gmail.com"},{"name":"amylily1011","email":"amy.lily@canonical.com"},{"name":"bartaz","email":"bartek.szopka@canonical.com"},{"name":"jpmartinspt","email":"joao.figueiredo.martins@canonical.com"},{"name":"petesfrench","email":"peterfrench94@gmail.com"},{"name":"mariadias143","email":"marianovadias@gmail.com"},{"name":"jmuzina","email":"jmuzina@pm.me"},{"name":"mtruj","email":"mariapaula.trujillo@canonical.com"},{"name":"edlerd","email":"david.edler@canonical.com"},{"name":"canonical-organization","email":"is-admin@canonical.com"},{"name":"edisile-canonical","email":"eduard.manta@canonical.com"},{"name":"steciuk-canonical","email":"adam.steciuk@canonical.com"},{"name":"ad.vl","email":"adrian.villa.g@gmail.com"},{"name":"engr-ali","email":"its.muhammad.ali.mughal@gmail.com"},{"name":"ando.gq","email":"tom@ando.sh"},{"name":"ninfa_jeon","email":"urvashi.sharma271099@gmail.com"},{"name":"ndv99","email":"n.devilliers1999@gmail.com"},{"name":"goulin-canonical","email":"goulin.khoge@canonical.com"},{"name":"immortalcodes","email":"21112002mj@gmail.com"},{"name":"alvaromateo","email":"alvaro.mateoalvarez@canonical.com"},{"name":"onibenjo-canonical","email":"benjaminaderopo.oni@canonical.com"}],"bin":{"collect-implementations":"src/collect-implementations.ts"},"dist":{"shasum":"349737cfe47e5ded4f3a0dd315dfb5f8ebb8d080","tarball":"https://registry.npmjs.org/@canonical/design-system/-/design-system-0.1.1.tgz","fileCount":291,"integrity":"sha512-Mc5pCTXLfF8hwwzG/FVWe0RQthzGhbXowjEVP55ZclbjAeglRHXvGxhgqo+MRfgoE5Pt6BHZkTVazL0dgr/3pA==","signatures":[{"sig":"MEYCIQCKWxtq5F6xgMOB6EYekn9YWLqNjCo68upBSXprP/DhewIhAMYTNaL6boBcUalYNDfgJ9B7Wo7FeJTZ47S6fwY1SkL8","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"unpackedSize":910954},"type":"module","types":"src/index.ts","module":"index.ts","gitHead":"c3a89a9b58947392bc0b5a7a6cd48e671a6ea9f8","scripts":{"test":"bun run test:vitest","build":"bun run ds:extract && bun run ds:transform","check":"bun run check:biome","ds:list":"bun src/cli.ts list source.json","check:ts":"tsc --noEmit","check:fix":"bun run check:biome:fix && bun run check:ts","ds:extract":"bun src/cli.ts extract source.json","check:biome":"biome check","test:vitest":"vitest run","ds:transform":"bun src/cli.ts transform source.json","check:biome:fix":"biome check --write","test:vitest:watch":"vitest","generate:coda-types":"openapi-typescript https://coda.io/apis/v1/openapi.json -o src/providers/CodaProvider.types.generated.ts"},"_npmUser":{"name":"ad.vl","email":"adrian.villa.g@gmail.com"},"_npmVersion":"11.6.2","description":"An OWL ontology for modeling UI design systems as structured, queryable knowledge graphs. Built to bridge the gap between design specifications and implementation by establishing a shared semantic vocabulary for components, patterns, layouts, and their re","directories":{},"_nodeVersion":"24.13.0","dependencies":{"n3":"^2.0.1","ajv":"^8.17.1","jsonld":"^9.0.0"},"_hasShrinkwrap":false,"devDependencies":{"vitest":"^4.0.18","@types/n3":"^1.26.1","@types/bun":"latest","@types/jsonld":"^1.5.15","@biomejs/biome":"^2.3.14","openapi-typescript":"^7.12.0","vite-tsconfig-paths":"^6.1.0","@canonical/biome-config":"^0.12.0","@canonical/typescript-config-react":"^0.12.0"},"_npmOperationalInternal":{"tmp":"tmp/design-system_0.1.1_1774047071414_0.09703544654945873","host":"s3://npm-registry-packages-npm-production"}},"0.1.2":{"name":"@canonical/design-system","version":"0.1.2","license":"LGPL-3.0","_id":"@canonical/design-system@0.1.2","maintainers":[{"name":"ilayda21","email":"ilayda.cavusoglupars@canonical.com"},{"name":"frankban","email":"frankban@gmail.com"},{"name":"huwshimi","email":"huw@ikmail.com"},{"name":"anthonydillon","email":"me@anthonydillon.com"},{"name":"steverydz","email":"steverydz@gmail.com"},{"name":"amylily1011","email":"amy.lily@canonical.com"},{"name":"bartaz","email":"bartek.szopka@canonical.com"},{"name":"jpmartinspt","email":"joao.figueiredo.martins@canonical.com"},{"name":"petesfrench","email":"peterfrench94@gmail.com"},{"name":"mariadias143","email":"marianovadias@gmail.com"},{"name":"jmuzina","email":"jmuzina@pm.me"},{"name":"mtruj","email":"mariapaula.trujillo@canonical.com"},{"name":"edlerd","email":"david.edler@canonical.com"},{"name":"canonical-organization","email":"is-admin@canonical.com"},{"name":"edisile-canonical","email":"eduard.manta@canonical.com"},{"name":"steciuk-canonical","email":"adam.steciuk@canonical.com"},{"name":"ad.vl","email":"adrian.villa.g@gmail.com"},{"name":"engr-ali","email":"its.muhammad.ali.mughal@gmail.com"},{"name":"ando.gq","email":"tom@ando.sh"},{"name":"ninfa_jeon","email":"urvashi.sharma271099@gmail.com"},{"name":"ndv99","email":"n.devilliers1999@gmail.com"},{"name":"goulin-canonical","email":"goulin.khoge@canonical.com"},{"name":"immortalcodes","email":"21112002mj@gmail.com"},{"name":"alvaromateo","email":"alvaro.mateoalvarez@canonical.com"},{"name":"onibenjo-canonical","email":"benjaminaderopo.oni@canonical.com"}],"bin":{"collect-implementations":"src/collect-implementations.ts"},"dist":{"shasum":"38d335f1c5b4a4fad0d727547fb533357a06524b","tarball":"https://registry.npmjs.org/@canonical/design-system/-/design-system-0.1.2.tgz","fileCount":292,"integrity":"sha512-uLfk3ul9dkk+4wV54uo1RqDU/++9lir+fBn0lCfwb+U+eZ97tg1yuQCiHaiMWTewW6nXNO82t7mgkMKf9h33nQ==","signatures":[{"sig":"MEYCIQCr2PgsAGV/uDzdQPMdie10JJ1Bsjm7ZiYiaY2u/QM73wIhAK4DaLun0g3VFGubZUIUtlo32Zq1D/PMs7ClGWMzOy5u","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"unpackedSize":854863},"type":"module","types":"src/index.ts","module":"index.ts","gitHead":"54cf3af1b5be47c646d31a90aaf75b919b296cae","scripts":{"test":"bun run test:vitest","build":"bun run ds:extract && bun run ds:transform","check":"bun run check:biome","ds:list":"bun src/cli.ts list source.json","check:ts":"tsc --noEmit","check:fix":"bun run check:biome:fix && bun run check:ts","ds:extract":"bun src/cli.ts extract source.json","check:biome":"biome check","test:vitest":"vitest run","ds:transform":"bun src/cli.ts transform source.json","check:biome:fix":"biome check --write","test:vitest:watch":"vitest","generate:coda-types":"openapi-typescript https://coda.io/apis/v1/openapi.json -o src/providers/CodaProvider.types.generated.ts"},"_npmUser":{"name":"ad.vl","email":"adrian.villa.g@gmail.com"},"_npmVersion":"11.6.2","description":"An OWL ontology for modeling UI design systems as structured, queryable knowledge graphs. Built to bridge the gap between design specifications and implementation by establishing a shared semantic vocabulary for components, patterns, layouts, and their re","directories":{},"_nodeVersion":"24.13.0","dependencies":{"n3":"^2.0.1","ajv":"^8.17.1","jsonld":"^9.0.0"},"_hasShrinkwrap":false,"devDependencies":{"vitest":"^4.0.18","@types/n3":"^1.26.1","@types/bun":"latest","@types/jsonld":"^1.5.15","@biomejs/biome":"^2.3.14","openapi-typescript":"^7.12.0","vite-tsconfig-paths":"^6.1.0","@canonical/biome-config":"^0.12.0","@canonical/typescript-config-react":"^0.12.0"},"_npmOperationalInternal":{"tmp":"tmp/design-system_0.1.2_1774202546135_0.5451931136258501","host":"s3://npm-registry-packages-npm-production"}},"0.2.0":{"name":"@canonical/design-system","version":"0.2.0","license":"LGPL-3.0","_id":"@canonical/design-system@0.2.0","maintainers":[{"name":"ilayda21","email":"ilayda.cavusoglupars@canonical.com"},{"name":"frankban","email":"frankban@gmail.com"},{"name":"huwshimi","email":"huw@ikmail.com"},{"name":"anthonydillon","email":"me@anthonydillon.com"},{"name":"steverydz","email":"steverydz@gmail.com"},{"name":"amylily1011","email":"amy.lily@canonical.com"},{"name":"bartaz","email":"bartek.szopka@canonical.com"},{"name":"jpmartinspt","email":"joao.figueiredo.martins@canonical.com"},{"name":"petesfrench","email":"peterfrench94@gmail.com"},{"name":"jmuzina","email":"jmuzina@pm.me"},{"name":"mtruj","email":"mariapaula.trujillo@canonical.com"},{"name":"edlerd","email":"david.edler@canonical.com"},{"name":"abehnia","email":"ardavan.behnia@canonical.com"},{"name":"canonical-organization","email":"is-admin@canonical.com"},{"name":"edisile-canonical","email":"eduard.manta@canonical.com"},{"name":"steciuk-canonical","email":"adam.steciuk@canonical.com"},{"name":"ad.vl","email":"adrian.villa.g@gmail.com"},{"name":"engr-ali","email":"its.muhammad.ali.mughal@gmail.com"},{"name":"ando.gq","email":"tom@ando.sh"},{"name":"ninfa_jeon","email":"urvashi.sharma271099@gmail.com"},{"name":"ndv99","email":"n.devilliers1999@gmail.com"},{"name":"goulin-canonical","email":"goulin.khoge@canonical.com"},{"name":"immortalcodes","email":"21112002mj@gmail.com"},{"name":"alvaromateo","email":"alvaro.mateoalvarez@canonical.com"},{"name":"onibenjo-canonical","email":"benjaminaderopo.oni@canonical.com"}],"bin":{"collect-implementations":"src/collect-implementations.ts"},"dist":{"shasum":"15a03ffbec48a6f3e24297ee6bd8b057d49b4cc4","tarball":"https://registry.npmjs.org/@canonical/design-system/-/design-system-0.2.0.tgz","fileCount":483,"integrity":"sha512-pCX4jrm1Q/U3g1h8QoND9i2qvrQIVQhOU4rcnXFx+XaRNqe4jNtBZTd/ad0J5J/PMmgrCIGF/qi0Q/aVajnWDQ==","signatures":[{"sig":"MEUCIQCyk9lDSnU/IpWfaTL27FfsUuSbMD3ypW+QMejmYjvhRwIgdQCXnWLfMqtOgPggD9rTUp5vxDasH+GFGyuelk3mmpw=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"unpackedSize":1633636},"type":"module","types":"src/index.ts","module":"index.ts","gitHead":"d4134fa00ba96f77813dc81cb0f42694b696254e","scripts":{"test":"bun run test:vitest","build":"bun run ds:extract && bun run ds:transform","check":"bun run check:biome","ds:list":"bun src/cli.ts list source.json","ds:sync":"bun src/cli.ts sync src/sync/form-roster.target.json","check:ts":"tsc --noEmit","check:fix":"bun run check:biome:fix && bun run check:ts","ds:extract":"bun src/cli.ts extract source.json","check:biome":"biome check","test:vitest":"vitest run","ds:transform":"bun src/cli.ts transform source.json","test:coverage":"vitest run --coverage","check:biome:fix":"biome check --write","test:vitest:watch":"vitest","generate:coda-types":"openapi-typescript https://coda.io/apis/v1/openapi.json -o src/providers/CodaProvider.types.generated.ts"},"_npmUser":{"name":"ad.vl","email":"adrian.villa.g@gmail.com"},"_npmVersion":"11.16.0","description":"An OWL ontology for modeling UI design systems as structured, queryable knowledge graphs. Built to bridge the gap between design specifications and implementation by establishing a shared semantic vocabulary for components, patterns, layouts, and their re","directories":{},"_nodeVersion":"24.18.1","dependencies":{"n3":"^2.0.1","ajv":"^8.17.1","jsonld":"^9.0.0"},"_hasShrinkwrap":false,"devDependencies":{"vitest":"^4.1.9","@types/n3":"^1.26.1","@types/bun":"latest","@types/jsonld":"^1.5.15","@biomejs/biome":"^2.3.14","openapi-typescript":"^7.12.0","@vitest/coverage-v8":"^4.1.9","vite-tsconfig-paths":"^6.1.0","@canonical/biome-config":"^0.12.0","@canonical/typescript-config-react":"^0.12.0"},"_npmOperationalInternal":{"tmp":"tmp/design-system_0.2.0_1787839523220_0.7481332677001062","host":"s3://npm-registry-packages-npm-production"}},"0.2.1":{"name":"@canonical/design-system","version":"0.2.1","license":"LGPL-3.0","_id":"@canonical/design-system@0.2.1","maintainers":[{"name":"ilayda21","email":"ilayda.cavusoglupars@canonical.com"},{"name":"frankban","email":"frankban@gmail.com"},{"name":"huwshimi","email":"huw@ikmail.com"},{"name":"anthonydillon","email":"me@anthonydillon.com"},{"name":"steverydz","email":"steverydz@gmail.com"},{"name":"amylily1011","email":"amy.lily@canonical.com"},{"name":"bartaz","email":"bartek.szopka@canonical.com"},{"name":"jpmartinspt","email":"joao.figueiredo.martins@canonical.com"},{"name":"petesfrench","email":"peterfrench94@gmail.com"},{"name":"jmuzina","email":"jmuzina@pm.me"},{"name":"mtruj","email":"mariapaula.trujillo@canonical.com"},{"name":"edlerd","email":"david.edler@canonical.com"},{"name":"abehnia","email":"ardavan.behnia@canonical.com"},{"name":"canonical-organization","email":"is-admin@canonical.com"},{"name":"edisile-canonical","email":"eduard.manta@canonical.com"},{"name":"steciuk-canonical","email":"adam.steciuk@canonical.com"},{"name":"ad.vl","email":"adrian.villa.g@gmail.com"},{"name":"engr-ali","email":"its.muhammad.ali.mughal@gmail.com"},{"name":"ando.gq","email":"tom@ando.sh"},{"name":"ninfa_jeon","email":"urvashi.sharma271099@gmail.com"},{"name":"ndv99","email":"n.devilliers1999@gmail.com"},{"name":"goulin-canonical","email":"goulin.khoge@canonical.com"},{"name":"immortalcodes","email":"21112002mj@gmail.com"},{"name":"alvaromateo","email":"alvaro.mateoalvarez@canonical.com"},{"name":"onibenjo-canonical","email":"benjaminaderopo.oni@canonical.com"}],"bin":{"collect-implementations":"src/collect-implementations.ts"},"dist":{"shasum":"6138c940015cbac0070291bf7909f241cccff950","tarball":"https://registry.npmjs.org/@canonical/design-system/-/design-system-0.2.1.tgz","fileCount":483,"integrity":"sha512-KO0yi5YnRhgeMirEfxI45HoJ0qB5krjl16H0Lyb7XYTiVkJ2JWCZlB9fv3t2Z2aVZRmkHewvpTk1qbhcug7n2g==","signatures":[{"sig":"MEUCIEM2G+8I1981DAcMVk/mtNN9SFl3SRhRrjn3rWcncEcvAiEAtDOeba/lcSPCcyABM155fmqeayBcwKtJzI4i0zTM9Ms=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"unpackedSize":1646361},"type":"module","types":"src/index.ts","module":"index.ts","gitHead":"6a2f76d7f45ce5c47bb5b936d4687da057b919e6","scripts":{"test":"bun run test:vitest","build":"bun run ds:extract && bun run ds:transform","check":"bun run check:biome","ds:list":"bun src/cli.ts list source.json","ds:sync":"bun src/cli.ts sync src/sync/form-roster.target.json","check:ts":"tsc --noEmit","check:fix":"bun run check:biome:fix && bun run check:ts","ds:extract":"bun src/cli.ts extract source.json","check:biome":"biome check","test:vitest":"vitest run","ds:transform":"bun src/cli.ts transform source.json","test:coverage":"vitest run --coverage","check:biome:fix":"biome check --write","test:vitest:watch":"vitest","generate:coda-types":"openapi-typescript https://coda.io/apis/v1/openapi.json -o src/providers/CodaProvider.types.generated.ts"},"_npmUser":{"name":"ad.vl","email":"adrian.villa.g@gmail.com"},"_npmVersion":"11.16.0","description":"An OWL ontology for modeling UI design systems as structured, queryable knowledge graphs. Built to bridge the gap between design specifications and implementation by establishing a shared semantic vocabulary for components, patterns, layouts, and their re","directories":{},"_nodeVersion":"24.18.1","dependencies":{"n3":"^2.0.1","ajv":"^8.17.1","jsonld":"^9.0.0"},"_hasShrinkwrap":false,"devDependencies":{"vitest":"^4.1.9","@types/n3":"^1.26.1","@types/bun":"latest","@types/jsonld":"^1.5.15","@biomejs/biome":"^2.3.14","openapi-typescript":"^7.12.0","@vitest/coverage-v8":"^4.1.9","vite-tsconfig-paths":"^6.1.0","@canonical/biome-config":"^0.12.0","@canonical/typescript-config-react":"^0.12.0"},"_npmOperationalInternal":{"tmp":"tmp/design-system_0.2.1_1787841421772_0.16725883033303046","host":"s3://npm-registry-packages-npm-production"}},"0.2.2":{"name":"@canonical/design-system","version":"0.2.2","license":"LGPL-3.0","_id":"@canonical/design-system@0.2.2","maintainers":[{"name":"ilayda21","email":"ilayda.cavusoglupars@canonical.com"},{"name":"frankban","email":"frankban@gmail.com"},{"name":"huwshimi","email":"huw@ikmail.com"},{"name":"anthonydillon","email":"me@anthonydillon.com"},{"name":"steverydz","email":"steverydz@gmail.com"},{"name":"amylily1011","email":"amy.lily@canonical.com"},{"name":"bartaz","email":"bartek.szopka@canonical.com"},{"name":"jpmartinspt","email":"joao.figueiredo.martins@canonical.com"},{"name":"petesfrench","email":"peterfrench94@gmail.com"},{"name":"jmuzina","email":"jmuzina@pm.me"},{"name":"mtruj","email":"mariapaula.trujillo@canonical.com"},{"name":"edlerd","email":"david.edler@canonical.com"},{"name":"abehnia","email":"ardavan.behnia@canonical.com"},{"name":"canonical-organization","email":"is-admin@canonical.com"},{"name":"edisile-canonical","email":"eduard.manta@canonical.com"},{"name":"steciuk-canonical","email":"adam.steciuk@canonical.com"},{"name":"ad.vl","email":"adrian.villa.g@gmail.com"},{"name":"engr-ali","email":"its.muhammad.ali.mughal@gmail.com"},{"name":"ando.gq","email":"tom@ando.sh"},{"name":"ninfa_jeon","email":"urvashi.sharma271099@gmail.com"},{"name":"ndv99","email":"n.devilliers1999@gmail.com"},{"name":"goulin-canonical","email":"goulin.khoge@canonical.com"},{"name":"immortalcodes","email":"21112002mj@gmail.com"},{"name":"alvaromateo","email":"alvaro.mateoalvarez@canonical.com"},{"name":"onibenjo-canonical","email":"benjaminaderopo.oni@canonical.com"}],"bin":{"collect-implementations":"src/collect-implementations.ts"},"dist":{"shasum":"5562f7f99c481fa4d8794ed261718b902903d645","tarball":"https://registry.npmjs.org/@canonical/design-system/-/design-system-0.2.2.tgz","fileCount":483,"integrity":"sha512-per6gSdBdOWLxgqYjQ3e2BMRgD6Ad02Qz3xBCu4cGUGwPMMB6FTp9pE+WePNgDv7Xz6IfyIQMlUKYTiB7FK7Pw==","signatures":[{"sig":"MEUCIQC+iZjhlYwpM4zle2rnHA76gzr/fBmehabZdmz3rYXHSwIgVnBPIfCHlKWWYDbR6vphWx8r0Bb4OtjMc4aOarYd1/g=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"unpackedSize":1653447},"type":"module","types":"src/index.ts","module":"index.ts","gitHead":"6a2f76d7f45ce5c47bb5b936d4687da057b919e6","scripts":{"test":"bun run test:vitest","build":"bun run ds:extract && bun run ds:transform","check":"bun run check:biome","ds:list":"bun src/cli.ts list source.json","ds:sync":"bun src/cli.ts sync src/sync/form-roster.target.json","check:ts":"tsc --noEmit","check:fix":"bun run check:biome:fix && bun run check:ts","ds:extract":"bun src/cli.ts extract source.json","check:biome":"biome check","test:vitest":"vitest run","ds:transform":"bun src/cli.ts transform source.json","test:coverage":"vitest run --coverage","check:biome:fix":"biome check --write","test:vitest:watch":"vitest","generate:coda-types":"openapi-typescript https://coda.io/apis/v1/openapi.json -o src/providers/CodaProvider.types.generated.ts"},"_npmUser":{"name":"ad.vl","email":"adrian.villa.g@gmail.com"},"_npmVersion":"11.16.0","description":"An OWL ontology for modeling UI design systems as structured, queryable knowledge graphs. Built to bridge the gap between design specifications and implementation by establishing a shared semantic vocabulary for components, patterns, layouts, and their re","directories":{},"_nodeVersion":"24.18.1","dependencies":{"n3":"^2.0.1","ajv":"^8.17.1","jsonld":"^9.0.0","tinyglobby":"^0.2.14"},"_hasShrinkwrap":false,"devDependencies":{"vitest":"^4.1.9","@types/n3":"^1.26.1","@types/bun":"latest","@types/jsonld":"^1.5.15","@biomejs/biome":"^2.3.14","openapi-typescript":"^7.12.0","@vitest/coverage-v8":"^4.1.9","vite-tsconfig-paths":"^6.1.0","@canonical/biome-config":"^0.12.0","@canonical/typescript-config-react":"^0.12.0"},"_npmOperationalInternal":{"tmp":"tmp/design-system_0.2.2_1787845160592_0.9197766223517003","host":"s3://npm-registry-packages-npm-production"}},"0.2.3":{"name":"@canonical/design-system","version":"0.2.3","license":"LGPL-3.0","_id":"@canonical/design-system@0.2.3","maintainers":[{"name":"ilayda21","email":"ilayda.cavusoglupars@canonical.com"},{"name":"frankban","email":"frankban@gmail.com"},{"name":"huwshimi","email":"huw@ikmail.com"},{"name":"anthonydillon","email":"me@anthonydillon.com"},{"name":"steverydz","email":"steverydz@gmail.com"},{"name":"amylily1011","email":"amy.lily@canonical.com"},{"name":"bartaz","email":"bartek.szopka@canonical.com"},{"name":"jpmartinspt","email":"joao.figueiredo.martins@canonical.com"},{"name":"petesfrench","email":"peterfrench94@gmail.com"},{"name":"jmuzina","email":"jmuzina@pm.me"},{"name":"mtruj","email":"mariapaula.trujillo@canonical.com"},{"name":"edlerd","email":"david.edler@canonical.com"},{"name":"abehnia","email":"ardavan.behnia@canonical.com"},{"name":"canonical-organization","email":"is-admin@canonical.com"},{"name":"edisile-canonical","email":"eduard.manta@canonical.com"},{"name":"steciuk-canonical","email":"adam.steciuk@canonical.com"},{"name":"ad.vl","email":"adrian.villa.g@gmail.com"},{"name":"engr-ali","email":"its.muhammad.ali.mughal@gmail.com"},{"name":"ando.gq","email":"tom@ando.sh"},{"name":"ninfa_jeon","email":"urvashi.sharma271099@gmail.com"},{"name":"ndv99","email":"n.devilliers1999@gmail.com"},{"name":"goulin-canonical","email":"goulin.khoge@canonical.com"},{"name":"immortalcodes","email":"21112002mj@gmail.com"},{"name":"alvaromateo","email":"alvaro.mateoalvarez@canonical.com"},{"name":"onibenjo-canonical","email":"benjaminaderopo.oni@canonical.com"}],"bin":{"collect-implementations":"src/collect-implementations.ts"},"dist":{"shasum":"ba46465ca67da3b0304f48a24b0b9a0d33744a08","tarball":"https://registry.npmjs.org/@canonical/design-system/-/design-system-0.2.3.tgz","fileCount":495,"integrity":"sha512-4l9v19xSkM4/gbsR4ny+VDnCuJ2uknTOA/JBkPJHca6DCsf9HtcmZwPMFnOt3HaFeD9b+G29fM0Uj53aYvLo6Q==","signatures":[{"sig":"MEYCIQDAq77oqG1qFKJ8gRcTdHR+iX4OJOtuBAZLHOl+o5r3xgIhAP1Nk7qVI1Sm3GRUtQ2wippyTNeNqzjgf8m6sM/HBsgZ","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"unpackedSize":1716384},"type":"module","types":"src/index.ts","module":"index.ts","gitHead":"f8fb157dca51f19c6b6f4b1526603483144ec2f7","scripts":{"test":"bun run test:vitest","build":"bun run ds:extract && bun run ds:transform","check":"bun run check:biome","ds:list":"bun src/cli.ts list source.json","ds:sync":"bun src/cli.ts sync src/sync/form-roster.target.json","check:ts":"tsc --noEmit","check:fix":"bun run check:biome:fix && bun run check:ts","ds:extract":"bun src/cli.ts extract source.json","check:biome":"biome check","test:vitest":"vitest run","ds:transform":"bun src/cli.ts transform source.json","test:coverage":"vitest run --coverage","check:biome:fix":"biome check --write","test:vitest:watch":"vitest","generate:coda-types":"openapi-typescript https://coda.io/apis/v1/openapi.json -o src/providers/CodaProvider.types.generated.ts"},"_npmUser":{"name":"ad.vl","email":"adrian.villa.g@gmail.com"},"_npmVersion":"11.16.0","description":"An OWL ontology for modeling UI design systems as structured, queryable knowledge graphs. Built to bridge the gap between design specifications and implementation by establishing a shared semantic vocabulary for components, patterns, layouts, and their re","directories":{},"_nodeVersion":"24.18.1","dependencies":{"n3":"^2.0.1","ajv":"^8.17.1","jsonld":"^9.0.0","tinyglobby":"^0.2.14"},"_hasShrinkwrap":false,"devDependencies":{"vitest":"^4.1.9","@types/n3":"^1.26.1","@types/bun":"latest","@types/jsonld":"^1.5.15","@biomejs/biome":"^2.3.14","openapi-typescript":"^7.12.0","@vitest/coverage-v8":"^4.1.9","vite-tsconfig-paths":"^6.1.0","@canonical/biome-config":"^0.12.0","@canonical/typescript-config-react":"^0.12.0"},"_npmOperationalInternal":{"tmp":"tmp/design-system_0.2.3_1787868228951_0.07790007799701826","host":"s3://npm-registry-packages-npm-production"}},"0.2.4":{"name":"@canonical/design-system","version":"0.2.4","license":"LGPL-3.0","_id":"@canonical/design-system@0.2.4","maintainers":[{"name":"ilayda21","email":"ilayda.cavusoglupars@canonical.com"},{"name":"frankban","email":"frankban@gmail.com"},{"name":"huwshimi","email":"huw@ikmail.com"},{"name":"anthonydillon","email":"me@anthonydillon.com"},{"name":"steverydz","email":"steverydz@gmail.com"},{"name":"amylily1011","email":"amy.lily@canonical.com"},{"name":"bartaz","email":"bartek.szopka@canonical.com"},{"name":"jpmartinspt","email":"joao.figueiredo.martins@canonical.com"},{"name":"petesfrench","email":"peterfrench94@gmail.com"},{"name":"jmuzina","email":"jmuzina@pm.me"},{"name":"mtruj","email":"mariapaula.trujillo@canonical.com"},{"name":"edlerd","email":"david.edler@canonical.com"},{"name":"abehnia","email":"ardavan.behnia@canonical.com"},{"name":"canonical-organization","email":"is-admin@canonical.com"},{"name":"edisile-canonical","email":"eduard.manta@canonical.com"},{"name":"steciuk-canonical","email":"adam.steciuk@canonical.com"},{"name":"ad.vl","email":"adrian.villa.g@gmail.com"},{"name":"engr-ali","email":"its.muhammad.ali.mughal@gmail.com"},{"name":"ando.gq","email":"tom@ando.sh"},{"name":"ninfa_jeon","email":"urvashi.sharma271099@gmail.com"},{"name":"ndv99","email":"n.devilliers1999@gmail.com"},{"name":"goulin-canonical","email":"goulin.khoge@canonical.com"},{"name":"immortalcodes","email":"21112002mj@gmail.com"},{"name":"alvaromateo","email":"alvaro.mateoalvarez@canonical.com"},{"name":"onibenjo-canonical","email":"benjaminaderopo.oni@canonical.com"}],"bin":{"collect-implementations":"src/collect-implementations.ts"},"dist":{"shasum":"2ee46b35a02222389b9b507f588b43a132ee4bac","tarball":"https://registry.npmjs.org/@canonical/design-system/-/design-system-0.2.4.tgz","fileCount":495,"integrity":"sha512-oP9ow2DbhQM9AUHAq+JwrLEe3sdsV8c+kqmsrt+rHjAq1eUBm/WYr6LIDEvjnxomHNgRZ0ZP097Mc0oCfhjiRQ==","signatures":[{"sig":"MEQCIFuae4cZRXc4FhdmTMhWUX3Oixs2y+jjCx1kc2TNh+4DAiA3rkAxIX93j0UNhQU2RKlF8Qd6LZ/05dBjqg0RaAMfKQ==","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"unpackedSize":1738529},"type":"module","types":"src/index.ts","module":"index.ts","gitHead":"a9edb8755a880a28798ad82d4c90bf9b6538c686","scripts":{"test":"bun run test:vitest","build":"bun run ds:extract && bun run ds:transform","check":"bun run check:biome","ds:list":"bun src/cli.ts list source.json","ds:sync":"bun src/cli.ts sync src/sync/form-roster.target.json","check:ts":"tsc --noEmit","check:fix":"bun run check:biome:fix && bun run check:ts","ds:extract":"bun src/cli.ts extract source.json","check:biome":"biome check","test:vitest":"vitest run","ds:transform":"bun src/cli.ts transform source.json","test:coverage":"vitest run --coverage","check:biome:fix":"biome check --write","test:vitest:watch":"vitest","generate:coda-types":"openapi-typescript https://coda.io/apis/v1/openapi.json -o src/providers/CodaProvider.types.generated.ts"},"_npmUser":{"name":"ad.vl","email":"adrian.villa.g@gmail.com"},"_npmVersion":"11.16.0","description":"An OWL ontology for modeling UI design systems as structured, queryable knowledge graphs. Built to bridge the gap between design specifications and implementation by establishing a shared semantic vocabulary for components, patterns, layouts, and their re","directories":{},"_nodeVersion":"24.18.1","dependencies":{"n3":"^2.0.1","ajv":"^8.17.1","jsonld":"^9.0.0","tinyglobby":"^0.2.14"},"_hasShrinkwrap":false,"devDependencies":{"vitest":"^4.1.9","@types/n3":"^1.26.1","@types/bun":"latest","@types/jsonld":"^1.5.15","@biomejs/biome":"^2.3.14","openapi-typescript":"^7.12.0","@vitest/coverage-v8":"^4.1.9","vite-tsconfig-paths":"^6.1.0","@canonical/biome-config":"^0.12.0","@canonical/typescript-config-react":"^0.12.0"},"_npmOperationalInternal":{"tmp":"tmp/design-system_0.2.4_1787869573067_0.30722020455077237","host":"s3://npm-registry-packages-npm-production"}},"0.2.5":{"name":"@canonical/design-system","version":"0.2.5","license":"LGPL-3.0","_id":"@canonical/design-system@0.2.5","maintainers":[{"name":"ilayda21","email":"ilayda.cavusoglupars@canonical.com"},{"name":"frankban","email":"frankban@gmail.com"},{"name":"huwshimi","email":"huw@ikmail.com"},{"name":"anthonydillon","email":"me@anthonydillon.com"},{"name":"steverydz","email":"steverydz@gmail.com"},{"name":"amylily1011","email":"amy.lily@canonical.com"},{"name":"bartaz","email":"bartek.szopka@canonical.com"},{"name":"jpmartinspt","email":"joao.figueiredo.martins@canonical.com"},{"name":"petesfrench","email":"peterfrench94@gmail.com"},{"name":"jmuzina","email":"jmuzina@pm.me"},{"name":"mtruj","email":"mariapaula.trujillo@canonical.com"},{"name":"edlerd","email":"david.edler@canonical.com"},{"name":"abehnia","email":"ardavan.behnia@canonical.com"},{"name":"canonical-organization","email":"is-admin@canonical.com"},{"name":"edisile-canonical","email":"eduard.manta@canonical.com"},{"name":"steciuk-canonical","email":"adam.steciuk@canonical.com"},{"name":"ad.vl","email":"adrian.villa.g@gmail.com"},{"name":"engr-ali","email":"its.muhammad.ali.mughal@gmail.com"},{"name":"ando.gq","email":"tom@ando.sh"},{"name":"ninfa_jeon","email":"urvashi.sharma271099@gmail.com"},{"name":"ndv99","email":"n.devilliers1999@gmail.com"},{"name":"goulin-canonical","email":"goulin.khoge@canonical.com"},{"name":"immortalcodes","email":"21112002mj@gmail.com"},{"name":"alvaromateo","email":"alvaro.mateoalvarez@canonical.com"},{"name":"onibenjo-canonical","email":"benjaminaderopo.oni@canonical.com"}],"bin":{"collect-implementations":"src/collect-implementations.ts"},"dist":{"shasum":"c6e3961954c919f23e4613dd7c3f4354e4f0a90e","tarball":"https://registry.npmjs.org/@canonical/design-system/-/design-system-0.2.5.tgz","fileCount":497,"integrity":"sha512-+J/GQ64Z+RHEC4fLYCcSV9CIVrIlYZQ2tpzG1mcpSWjs9foFZmvbCKfhxyMzPxx9RZNeNX2PfnBixWpdyBgPoQ==","signatures":[{"sig":"MEUCIEGl2B1FF44kvdrE9gUk0Ud8QZ5kIiUEJYuOh/QRLsk0AiEAg/3M8htGCPCXhyjIOwRHC+O8s5ORx0/RQzZ5DCfDZmU=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"unpackedSize":1759743},"type":"module","types":"src/index.ts","module":"index.ts","gitHead":"ce00818852628857da9c4a67bf8556c7cfda287d","scripts":{"test":"bun run test:vitest","build":"bun run ds:extract && bun run ds:transform","check":"bun run check:biome","ds:list":"bun src/cli.ts list source.json","ds:sync":"bun src/cli.ts sync src/sync/form-roster.target.json","check:ts":"tsc --noEmit","check:fix":"bun run check:biome:fix && bun run check:ts","ds:extract":"bun src/cli.ts extract source.json","check:biome":"biome check","test:vitest":"vitest run","ds:transform":"bun src/cli.ts transform source.json","test:coverage":"vitest run --coverage","check:biome:fix":"biome check --write","test:vitest:watch":"vitest","generate:coda-types":"openapi-typescript https://coda.io/apis/v1/openapi.json -o src/providers/CodaProvider.types.generated.ts"},"_npmUser":{"name":"ad.vl","email":"adrian.villa.g@gmail.com"},"_npmVersion":"11.16.0","description":"An OWL ontology for modeling UI design systems as structured, queryable knowledge graphs. Built to bridge the gap between design specifications and implementation by establishing a shared semantic vocabulary for components, patterns, layouts, and their re","directories":{},"_nodeVersion":"24.18.1","dependencies":{"n3":"^2.0.1","ajv":"^8.17.1","jsonld":"^9.0.0","tinyglobby":"^0.2.14"},"_hasShrinkwrap":false,"devDependencies":{"vitest":"^4.1.9","@types/n3":"^1.26.1","@types/bun":"latest","@types/jsonld":"^1.5.15","@biomejs/biome":"^2.3.14","openapi-typescript":"^7.12.0","@vitest/coverage-v8":"^4.1.9","vite-tsconfig-paths":"^6.1.0","@canonical/biome-config":"^0.12.0","@canonical/typescript-config-react":"^0.12.0"},"_npmOperationalInternal":{"tmp":"tmp/design-system_0.2.5_1787870266720_0.6422983771204525","host":"s3://npm-registry-packages-npm-production"}},"0.43.0-experimental.1":{"name":"@canonical/design-system","version":"0.43.0-experimental.1","license":"LGPL-3.0","_id":"@canonical/design-system@0.43.0-experimental.1","maintainers":[{"name":"ilayda21","email":"ilayda.cavusoglupars@canonical.com"},{"name":"frankban","email":"frankban@gmail.com"},{"name":"huwshimi","email":"huw@ikmail.com"},{"name":"anthonydillon","email":"me@anthonydillon.com"},{"name":"steverydz","email":"steverydz@gmail.com"},{"name":"bartaz","email":"bartek.szopka@canonical.com"},{"name":"jpmartinspt","email":"joao.figueiredo.martins@canonical.com"},{"name":"petesfrench","email":"peterfrench94@gmail.com"},{"name":"jmuzina","email":"jmuzina@pm.me"},{"name":"mtruj","email":"mariapaula.trujillo@canonical.com"},{"name":"edlerd","email":"david.edler@canonical.com"},{"name":"abehnia","email":"ardavan.behnia@canonical.com"},{"name":"canonical-organization","email":"is-admin@canonical.com"},{"name":"edisile-canonical","email":"eduard.manta@canonical.com"},{"name":"steciuk-canonical","email":"adam.steciuk@canonical.com"},{"name":"abbiesims","email":"abbie.sims@canonical.com"},{"name":"ataku_b","email":"atakan99saglam@gmail.com"},{"name":"ad.vl","email":"adrian.villa.g@gmail.com"},{"name":"engr-ali","email":"its.muhammad.ali.mughal@gmail.com"},{"name":"ninfa_jeon","email":"urvashi.sharma271099@gmail.com"},{"name":"ndv99","email":"n.devilliers1999@gmail.com"},{"name":"goulin-canonical","email":"goulin.khoge@canonical.com"},{"name":"immortalcodes","email":"21112002mj@gmail.com"},{"name":"alvaromateo","email":"alvaro.mateoalvarez@canonical.com"},{"name":"onibenjo-canonical","email":"benjaminaderopo.oni@canonical.com"}],"homepage":"https://github.com/canonical/pragma-core#readme","bugs":{"url":"https://github.com/canonical/pragma-core/issues"},"bin":{"collect-implementations":"src/collect-implementations.ts"},"dist":{"shasum":"c33d482f05eb1f1e3a097a9673372f868887ce7b","tarball":"https://registry.npmjs.org/@canonical/design-system/-/design-system-0.43.0-experimental.1.tgz","fileCount":492,"integrity":"sha512-R07OpMJKi+RdrVcfgbHl/NlFl0ARFwXsfjNY99SlwBzGo9IuDHt2i1PqortGES7p/rmVWOXFcqUF46JYBjNX3Q==","signatures":[{"sig":"MEUCIQCS8hbDATW1f/n/ey1/piO/KvdOEl17cAFcdUYd7bhZPQIgB/VOM4v9PF0l9GDhKE16UXx+Gg7yHmWD+9182oiJrlo=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"},{"sig":"MEUCIEQd7XDClDW15XC/k1RBT6wEyN313AUNWa3t97RJxph4AiEAs3blKBQvhkmQloVWsN2xvvjGhxSRP4dgEdlfggnWsEI=","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@canonical%2fdesign-system@0.43.0-experimental.1","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":2268891},"type":"module","types":"src/index.ts","module":"index.ts","gitHead":"5c1b1bdbb95844fac6211f1fe6ba10c29238d6ee","scripts":{"test":"bun run test:vitest","build":"echo 'No build step: data/ and definitions/ are published as committed'","check":"bun run check:biome","ds:list":"bun src/cli.ts list source.json","ds:sync":"bun src/cli.ts sync src/sync/form-roster.target.json","check:ts":"tsc --noEmit","check:fix":"bun run check:biome:fix && bun run check:ts","sync:coda":"bun run ds:extract && bun run ds:transform","ds:extract":"bun src/cli.ts extract source.json","check:biome":"biome check","test:vitest":"vitest run","ds:anatomies":"bun src/cli.ts anatomies","ds:transform":"bun src/cli.ts transform source.json","test:coverage":"vitest run --coverage","check:biome:fix":"biome check --write","test:vitest:watch":"vitest","generate:coda-types":"openapi-typescript https://coda.io/apis/v1/openapi.json -o src/providers/CodaProvider.types.generated.ts"},"_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"9ab6eec0-47b5-4f6b-a829-afd354d3dd18"}},"repository":{"url":"git+https://github.com/canonical/pragma-core.git","type":"git"},"_npmVersion":"lerna/10.0.1/node@v24.21.0+x64 (linux)","description":"An OWL ontology for modeling UI design systems as structured, queryable knowledge graphs. Built to bridge the gap between design specifications and implementation by establishing a shared semantic vocabulary for components, patterns, layouts, and their re","directories":{},"_nodeVersion":"24.21.0","dependencies":{"n3":"^2.0.1","ajv":"^8.17.1","yaml":"^2.7.1","jsonld":"^9.0.0","tinyglobby":"^0.2.14","@canonical/anatomy-dsl":"^0.43.0-experimental.1","@canonical/token-ontology":"^0.43.0-experimental.1"},"_hasShrinkwrap":false,"readmeFilename":"README.md","devDependencies":{"vite":"^7.2.6","vitest":"^4.1.9","@types/n3":"^1.26.1","@types/bun":"latest","typescript":"^7.0.2","@types/node":"^24.10.1","@types/jsonld":"^1.5.15","@biomejs/biome":"^2.3.14","openapi-typescript":"^7.12.0","@vitest/coverage-v8":"^4.1.9","vite-tsconfig-paths":"^6.1.0","@canonical/biome-config":"^0.43.0-experimental.0","@canonical/typescript-config":"^0.43.0-experimental.0"},"_npmOperationalInternal":{"tmp":"tmp/design-system_0.43.0-experimental.1_1790650015874_0.8845567615692844","host":"s3://npm-registry-packages-npm-production"}},"0.43.0":{"_id":"@canonical/design-system@0.43.0","bin":{"collect-implementations":"src/collect-implementations.ts"},"bugs":{"url":"https://github.com/canonical/pragma-core/issues"},"dist":{"shasum":"7fb8f66eb04464f0d101888073b16122078ca99f","tarball":"https://registry.npmjs.org/@canonical/design-system/-/design-system-0.43.0.tgz","fileCount":492,"integrity":"sha512-JnQyVqUoLS8VC/zwShjG6gauuJI8gzN9WVNh6vg8XGzx7I+hM63Nw+0/PrGprQzE3mxAoTF8t5s6ccGrgLOalg==","signatures":[{"sig":"MEQCIGSYB2WcbMY3vnkLdrRdfN0TBpE6JEUYoRUVfByOyPzFAiBbVDk4N8PCtAJJqyYK6281LxUgAD2Qgwe+LKeZ7XydUA==","keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U"},{"keyid":"SHA256:DhQ8wR5APBvFHLF/+Tc+AYvPOdTpcIDqOhxsBHRwC7U","sig":"MEQCICH8ppdYM6IbU9ysqqoAbAdf51nD1pfEyGr/2m2PSLjSAiARAPileOVCNg94ZFSlqaupSYthum5MIrYCskx3gZbbwA=="}],"attestations":{"url":"https://registry.npmjs.org/-/npm/v1/attestations/@canonical%2fdesign-system@0.43.0","provenance":{"predicateType":"https://slsa.dev/provenance/v1"}},"unpackedSize":2268816},"name":"@canonical/design-system","type":"module","types":"src/index.ts","module":"index.ts","gitHead":"79f70779057238803359b820183de972b4a1220c","license":"LGPL-3.0","scripts":{"test":"bun run test:vitest","build":"echo 'No build step: data/ and definitions/ are published as committed'","check":"bun run check:biome","ds:list":"bun src/cli.ts list source.json","ds:sync":"bun src/cli.ts sync src/sync/form-roster.target.json","check:ts":"tsc --noEmit","check:fix":"bun run check:biome:fix && bun run check:ts","sync:coda":"bun run ds:extract && bun run ds:transform","ds:extract":"bun src/cli.ts extract source.json","check:biome":"biome check","test:vitest":"vitest run","ds:anatomies":"bun src/cli.ts anatomies","ds:transform":"bun src/cli.ts transform source.json","test:coverage":"vitest run --coverage","check:biome:fix":"biome check --write","test:vitest:watch":"vitest","generate:coda-types":"openapi-typescript https://coda.io/apis/v1/openapi.json -o src/providers/CodaProvider.types.generated.ts"},"version":"0.43.0","_npmUser":{"name":"GitHub Actions","email":"npm-oidc-no-reply@github.com","trustedPublisher":{"id":"github","oidcConfigId":"9ab6eec0-47b5-4f6b-a829-afd354d3dd18"}},"homepage":"https://github.com/canonical/pragma-core#readme","repository":{"url":"git+https://github.com/canonical/pragma-core.git","type":"git"},"_npmVersion":"lerna/10.0.1/node@v24.21.0+x64 (linux)","description":"An OWL ontology for modeling UI design systems as structured, queryable knowledge graphs. Built to bridge the gap between design specifications and implementation by establishing a shared semantic vocabulary for components, patterns, layouts, and their re","directories":{},"maintainers":[{"name":"ilayda21","email":"ilayda.cavusoglupars@canonical.com"},{"name":"frankban","email":"frankban@gmail.com"},{"name":"huwshimi","email":"huw@ikmail.com"},{"name":"anthonydillon","email":"me@anthonydillon.com"},{"name":"steverydz","email":"steverydz@gmail.com"},{"name":"bartaz","email":"bartek.szopka@canonical.com"},{"name":"jpmartinspt","email":"joao.figueiredo.martins@canonical.com"},{"name":"petesfrench","email":"peterfrench94@gmail.com"},{"name":"jmuzina","email":"jmuzina@pm.me"},{"name":"mtruj","email":"mariapaula.trujillo@canonical.com"},{"name":"edlerd","email":"david.edler@canonical.com"},{"name":"abehnia","email":"ardavan.behnia@canonical.com"},{"name":"canonical-organization","email":"is-admin@canonical.com"},{"name":"edisile-canonical","email":"eduard.manta@canonical.com"},{"name":"steciuk-canonical","email":"adam.steciuk@canonical.com"},{"name":"abbiesims","email":"abbie.sims@canonical.com"},{"name":"ataku_b","email":"atakan99saglam@gmail.com"},{"name":"ad.vl","email":"adrian.villa.g@gmail.com"},{"name":"engr-ali","email":"its.muhammad.ali.mughal@gmail.com"},{"name":"ninfa_jeon","email":"urvashi.sharma271099@gmail.com"},{"name":"ndv99","email":"n.devilliers1999@gmail.com"},{"name":"goulin-canonical","email":"goulin.khoge@canonical.com"},{"name":"immortalcodes","email":"21112002mj@gmail.com"},{"name":"alvaromateo","email":"alvaro.mateoalvarez@canonical.com"},{"name":"onibenjo-canonical","email":"benjaminaderopo.oni@canonical.com"}],"_nodeVersion":"24.21.0","dependencies":{"n3":"^2.0.1","ajv":"^8.17.1","yaml":"^2.7.1","jsonld":"^9.0.0","tinyglobby":"^0.2.14","@canonical/anatomy-dsl":"^0.43.0","@canonical/token-ontology":"^0.43.0"},"_hasShrinkwrap":false,"devDependencies":{"vite":"^7.2.6","vitest":"^4.1.9","@types/n3":"^1.26.1","@types/bun":"latest","typescript":"^7.0.2","@types/node":"^24.10.1","@types/jsonld":"^1.5.15","@biomejs/biome":"^2.3.14","openapi-typescript":"^7.12.0","@vitest/coverage-v8":"^4.1.9","vite-tsconfig-paths":"^6.1.0","@canonical/biome-config":"^0.43.0","@canonical/typescript-config":"^0.43.0"},"_npmOperationalInternal":{"host":"s3://npm-registry-packages-npm-production","tmp":"tmp/design-system_0.43.0_1790797760006_0.5438605404735779"}}},"time":{"created":"2026-01-20T17:59:53.228Z","modified":"2026-09-30T19:49:20.550Z","0.1.0":"2026-01-20T17:59:53.551Z","0.1.1":"2026-03-20T22:51:11.651Z","0.1.2":"2026-03-22T18:02:26.357Z","0.2.0":"2026-08-27T14:05:23.377Z","0.2.1":"2026-08-27T14:37:01.912Z","0.2.2":"2026-08-27T15:39:20.748Z","0.2.3":"2026-08-27T22:03:49.152Z","0.2.4":"2026-08-27T22:26:13.250Z","0.2.5":"2026-08-27T22:37:46.879Z","0.43.0-experimental.1":"2026-09-29T02:46:56.019Z","0.43.0":"2026-09-30T19:49:20.108Z"},"license":"LGPL-3.0","description":"An OWL ontology for modeling UI design systems as structured, queryable knowledge graphs. Built to bridge the gap between design specifications and implementation by establishing a shared semantic vocabulary for components, patterns, layouts, and their re","maintainers":[{"name":"ilayda21","email":"ilayda.cavusoglupars@canonical.com"},{"name":"frankban","email":"frankban@gmail.com"},{"name":"huwshimi","email":"huw@ikmail.com"},{"name":"anthonydillon","email":"me@anthonydillon.com"},{"name":"steverydz","email":"steverydz@gmail.com"},{"name":"bartaz","email":"bartek.szopka@canonical.com"},{"name":"jpmartinspt","email":"joao.figueiredo.martins@canonical.com"},{"name":"petesfrench","email":"peterfrench94@gmail.com"},{"name":"jmuzina","email":"jmuzina@pm.me"},{"name":"mtruj","email":"mariapaula.trujillo@canonical.com"},{"name":"edlerd","email":"david.edler@canonical.com"},{"name":"abehnia","email":"ardavan.behnia@canonical.com"},{"name":"canonical-organization","email":"is-admin@canonical.com"},{"name":"edisile-canonical","email":"eduard.manta@canonical.com"},{"name":"steciuk-canonical","email":"adam.steciuk@canonical.com"},{"name":"abbiesims","email":"abbie.sims@canonical.com"},{"name":"ataku_b","email":"atakan99saglam@gmail.com"},{"name":"ad.vl","email":"adrian.villa.g@gmail.com"},{"name":"engr-ali","email":"its.muhammad.ali.mughal@gmail.com"},{"name":"ninfa_jeon","email":"urvashi.sharma271099@gmail.com"},{"name":"ndv99","email":"n.devilliers1999@gmail.com"},{"name":"goulin-canonical","email":"goulin.khoge@canonical.com"},{"name":"immortalcodes","email":"21112002mj@gmail.com"},{"name":"alvaromateo","email":"alvaro.mateoalvarez@canonical.com"},{"name":"onibenjo-canonical","email":"benjaminaderopo.oni@canonical.com"}],"readme":"# Design System Ontology\n\nAn OWL ontology for modeling UI design systems as structured, queryable knowledge graphs. Built to bridge the gap between design specifications and implementation by establishing a shared semantic vocabulary for components, patterns, layouts, and their relationships.\n\n**Core Philosophy:** A design system is more than a component library - it's a formal language. By modeling UI elements ontologically, we enable machine-readable specifications, automated consistency checking, and intelligent tooling that understands design intent.\n\n---\n\n## Quick Start\n\n### 1. Core Concepts\n\nThe ontology organizes UI elements into a hierarchy:\n\n```\nUIElement (root)\n└── UIBlock (visual/abstract entity for composing UIs)\n    ├── Component  - Implementable UI piece (Button, Badge, Card...)\n    ├── Pattern    - Reusable solution to UX problems\n    ├── Layout     - Opinionated space division for navigation\n    ├── Subcomponent - Part of a parent component\n    └── Group      - Repeating series of one sibling block (Cards, Tiles...)\n```\n\nComponents are organized by **Tiers** (scope/applicability) and can be customized through **ModifierFamilies** (variant axes). The diagram is an overview, not the class list — run `pragma ontology lookup ds` for the full hierarchy (Modifier and ModifierFamily sit under UIElement too).\n\n### 2. Defining a Component\n\n```turtle\n@prefix ds: <https://ds.canonical.com/> .\n\nds:global.component.button a ds:Component ;\n    ds:name \"Button\" ;\n    ds:summary \"Buttons trigger actions within an interface\" ;\n    ds:tier ds:global ;\n    ds:hasModifierFamily ds:global.modifier_family.importance ;\n    ds:usage \"\"\"### When to use\nFor primary actions that transform or submit data\n\n### When not to use\nFor navigation - use links instead\"\"\" .\n```\n\n### 3. Tiered Organization\n\nComponents belong to tiers that define their scope — `global` blocks are universal,\nthe `apps*` tiers scope application UI (shared or per-app), and further tiers cover\ntheir own surfaces. The tier set is live graph data; query it, never copy it:\n\n```bash\npragma tier list   # every tier that exists today, with display names\n```\n\n### 4. Modifier System\n\nModifiers provide systematic variation through **ModifierFamilies**:\n\n```turtle\nds:global.modifier_family.importance a ds:ModifierFamily ;\n    ds:name \"Importance\" ;\n    ds:hasModifier ds:global.modifier.primary,\n                    ds:global.modifier.secondary,\n                    ds:global.modifier.tertiary .\n\nds:global.component.button\n    ds:hasModifierFamily ds:global.modifier_family.importance .\n```\n\nThe families and their values are live graph data:\n\n```bash\npragma modifier list             # every family with its values\npragma modifier lookup <Family>  # one family in full — take the name from the list output\n```\n\n---\n\n## How-To Guides\n\n### How to Add a New Component\n\n1. Determine the appropriate tier based on scope\n2. Draft the spec as a standalone file under `specs/` (see `specs/README.md`) — never\n   hand-edit `data/`, it is regenerated destructively from Coda; a human enters the\n   finished spec into Coda\n3. Define required properties: name, summary, tier\n4. Link to applicable modifier families\n5. Add usage guidelines (`ds:usage`, with `### When to use` / `### When not to use`\n   sub-sections)\n\n```turtle\n@prefix ds: <https://ds.canonical.com/> .\n\nds:apps.component.file_tree a ds:Component ;\n    ds:name \"FileTree\" ;\n    ds:summary \"Hierarchical file browser for navigating directory structures\" ;\n    ds:tier ds:apps ;\n    ds:usage \"### When to use\\nWhen users need to navigate nested file hierarchies\" ;\n    ds:figmaLink <https://figma.com/file/...> .\n```\n\n### How to Define a Layout\n\nLayouts define how space is divided for a domain of information:\n\n```turtle\nds:apps.layout.sidebar a ds:Layout ;\n    ds:name \"Sidebar Layout\" ;\n    ds:domain \"Application navigation\" ;\n    ds:grid \"1fr 4fr\" ;\n    ds:gridAreas \"sidebar main\" ;\n    ds:targetDevices \"desktop, tablet\" .\n```\n\n### How to Create a Pattern\n\nPatterns are reusable solutions to UX problems:\n\n```turtle\nds:global.pattern.empty_state a ds:Pattern ;\n    ds:name \"Empty State\" ;\n    ds:summary \"Guidance shown when a container has no content\" ;\n    ds:tier ds:global ;\n    ds:usage \"### When to use\\nWhen a list, table, or container is empty\" ;\n    ds:guidelines \"Include illustration, message, and action\" .\n```\n\n### How to Model Component Composition\n\nUse subcomponents for parts that belong to a parent — the live Card.Header, for\nexample:\n\n```turtle\nds:global.subcomponent.card-header a ds:Subcomponent ;\n    ds:name \"Card.Header\" ;\n    ds:parentComponent ds:global.component.card .\n```\n\nOnly parts a user instantiates in their own code (`<Card.Header>`) get a\nsubcomponent entry; a part the user cannot write as `<Parent.Part>` belongs in the\nparent's anatomy as an anonymous role, not here (Button's icon is a role, not a\nsubcomponent).\n\n### How to Query the Design System\n\nUsing the pragma CLI:\n\n```bash\n# every component, pattern, layout and subcomponent, with its type and tier\npragma block list\n\n# Every triple on a specific block\npragma graph inspect ds:global.component.button\n\n# Arbitrary SPARQL — e.g. components drawing from a modifier family (a local\n# name with more than one dot does not parse in a query body; use the full IRI)\npragma graph query \"SELECT ?c WHERE { ?c ds:hasModifierFamily <https://ds.canonical.com/global.modifier_family.criticality> }\"\n```\n\n---\n\n## Reference\n\n### Classes\n\n| Class | Description |\n|-------|-------------|\n| `UIElement` | Root class for all design system entities |\n| `UIBlock` | Visual/abstract entity for composing UIs |\n| `Component` | Implementable UI piece |\n| `Pattern` | Reusable UX solution |\n| `Layout` | Space division for navigation |\n| `Subcomponent` | Part of a component |\n| `Modifier` | Variant option |\n| `ModifierFamily` | Grouping of related modifiers |\n| `Tier` | Scope/applicability level |\n| `Property` | Configurable component property |\n| `ImplementationObject` | Platform-specific implementation |\n| `ImplementationLibrary` | Implementation library |\n| `TokenBinding` | One symbol a block consumes, at one node, key, state and rank |\n\nRun `pragma ontology lookup ds` for the full class list with today's instance\ncounts (it also carries classes this overview omits).\n\n### UIBlock Properties\n\n| Property | Range | Description |\n|----------|-------|-------------|\n| `name` | string | Display name (from `Entity`) |\n| `summary` | string | What this block is/does (from `Entity`) |\n| `tier` | Tier | Scope classification |\n| `usage` | string | Usage guidance (`### When to use` / `### When not to use` sections) |\n| `guidelines` | string | Design guidelines |\n| `figmaLink` | anyURI | Link to Figma designs |\n| `anatomyDsl` | string | Anatomy in the Anatomy DSL (YAML) |\n| `anatomyClassic` | string | Anatomy as links/prose |\n| `hasVariant` | UIBlock | Variant blocks |\n| `hasModifierFamily` | ModifierFamily | Applicable variant axes |\n| `hasProperty` | Property | Configurable properties |\n\nRun `pragma ontology lookup ds --class UIBlock` for the full declared set —\n`documentationStage`, `changeLog`, and the variant/inheritance links are there too\n(`name` and `summary` are inherited from `Entity`; `--class Entity` shows them).\n\n### Layout-Specific Properties\n\n| Property | Range | Description |\n|----------|-------|-------------|\n| `domain` | string | Information domain |\n| `grid` | string | CSS grid definition |\n| `gridAreas` | string | Named grid areas |\n| `targetDevices` | string | Supported devices |\n\n### Component Relationships\n\n| Property | Domain | Range | Description |\n|----------|--------|-------|-------------|\n| `hasSubcomponent` | Component | Subcomponent | Composition |\n| `parentComponent` | Subcomponent | Component | Inverse of above |\n| `hasModifierFamily` | UIBlock | ModifierFamily | Variant axes |\n| `hasModifier` | ModifierFamily | Modifier | Variant options |\n\n### Implementation Bridge\n\n| Property | Domain | Range | Description |\n|----------|--------|-------|-------------|\n| `implementsBlock` | ImplementationObject | UIBlock | Links code to spec |\n| `library` | ImplementationObject | ImplementationLibrary | Source library |\n| `libraryTier` | ImplementationLibrary | Tier | Library's tier |\n\n### Token Bindings\n\n`ds:TokenBinding` records are **derived**, not authored: `deriveTokenBindings`\n(`src/transform/tokenBindings.ts`) is their only writer and runs as a post-step of the\ntransform, parsing each block's `ds:anatomyDsl` literal with `@canonical/anatomy-dsl`\nand following its `uri:` references transitively. A record is a blank node in the\nblock's own per-instance file.\n\n| Property | Domain | Range | Description |\n|----------|--------|-------|-------------|\n| `hasTokenBinding` | UIBlock | TokenBinding | A symbol this block consumes |\n| `consumesSymbol` | TokenBinding | `dt:TokenSymbol` | The symbol — exactly one, determined by the identity |\n| `viaBlock` | TokenBinding | UIBlock | The tree it was reached through; equal to the block for an own-tree binding |\n| `node` | TokenBinding | string | The node's tree path (`$root/nav list/level-1 entry/link`) |\n| `styleKey` | TokenBinding | string | `anatomy:styleKey`, reused from the anatomy vocabulary |\n| `styleState` | TokenBinding | string | `anatomy:styleState`; `\"default\"` for the unmarked key |\n| `rank` | TokenBinding | integer | 1-based position in the value's fallback order |\n\nThe identity is the six-tuple `(block, viaBlock, node, styleKey, styleState, rank)`;\n`consumesSymbol` is functionally determined by it. An inherited binding is therefore\njust `FILTER(?via != ?block)`:\n\n```sparql\nSELECT ?block ?key ?sym WHERE {\n  ?block ds:hasTokenBinding ?b .\n  ?b ds:consumesSymbol ?sym ; anatomy:styleKey ?key ; ds:viaBlock ?via .\n  FILTER(?via != ?block)\n}\n```\n\nThe node is a **path**, not a role, because a role alone collides:\n`global.pattern.table_of_contents` binds `role: link` at three depths with identical\nstyles. No parsed anatomy tree is written to the graph — the literal ships, and a\nconsumer that wants the tree parses it with the package.\n\n---\n\n## Explanation\n\n### Why an Ontology?\n\nAfter a decade using Vanilla Framework (CSS library), Canonical observed that visual consistency worked well but led to challenges:\n\n1. **Inconsistent terminology** - Same component, different names across teams\n2. **Implicit relationships** - Component composition undocumented\n3. **Lost design rationale** - Why decisions were made\n4. **Fragmented specifications** - Figma, docs, code out of sync\n\nAn ontology addresses these by:\n- **Establishing shared vocabulary** - One name, one meaning\n- **Explicit relationships** - Queryable component graph\n- **Structured metadata** - Guidelines, rationale, links preserved\n- **Machine-readable specs** - Enables tooling and validation\n\n### Design Principles\n\n**1. Separation of Concept and Implementation**\n\nThe ontology separates the *what* (UIBlock) from the *how* (ImplementationObject). A Button concept can have multiple implementations across React, Web Components, or Flutter while maintaining semantic identity.\n\n**2. Tiered Scoping**\n\nNot all components belong everywhere. Tiers make scope explicit - global components are universal, while apps-tier components may not make sense on marketing sites.\n\n**3. Systematic Variation**\n\nModifierFamilies provide principled variation. Instead of ad-hoc props like `isImportant`, `isPrimary`, `variant=\"critical\"`, the ontology models Importance and Criticality as distinct axes that components can opt into.\n\n**4. Documentation as Data**\n\nUsage guidelines, when-to-use patterns, and design rationale are first-class properties - queryable, versionable, and programmatically accessible.\n\n---\n\n## Architecture\n\n```\ndesign-system/\n├── definitions/\n│   └── ontology.ttl          # TBox: Classes, properties\n├── data/                     # Instance data — regenerated from Coda, never hand-edited\n│   ├── global/               # Global tier instances\n│   │   ├── component/        # Button, Badge, Card...\n│   │   ├── subcomponent/     # Card.Header, Accordion.Item...\n│   │   ├── group/            # Cards, Tiles...\n│   │   ├── pattern/          # Empty state, Loading...\n│   │   ├── layout/           # Grid layouts\n│   │   ├── modifier/         # Primary, Secondary...\n│   │   ├── modifier_family/  # Importance, Criticality...\n│   │   └── ...               # Other block classes\n│   ├── apps/                 # Apps tier\n│   ├── sites/                # Sites tier\n│   └── ...                   # Other tiers\n├── specs/                    # Drafted block specs — not read by build or sync\n├── skills/                   # Agent skills (installed via pragma sources update)\n├── src/                      # Build, sync, and collector source (TypeScript)\n├── examples/                 # Example files (sync target projection)\n└── README.md                 # This file\n```\n\n### Namespaces\n\n```turtle\n@prefix ds: <https://ds.canonical.com/> .  # Unified namespace for ontology and instances\n```\n\n### URI Convention\n\nInstances follow the pattern: `{tier}.{class}.{name}`\n\n```\nds:global.component.button\nds:apps.layout.application_layout\nds:global.modifier_family.importance\n```\n\n### Dependencies\n\nRuntime dependencies are declared in `package.json`; read them there, never from this\nfile.\n\nTwo of them carry the anatomy–token seam. `@canonical/anatomy-dsl` supplies the\nanatomy parser, the value grammar (`liftSymbols`) and the style-key roster\n(`STYLE_KEYS`, `takesToken`, `definitions/registry.ttl`); `@canonical/token-ontology`\nsupplies the token strata as data (`data/s1.ttl`, `data/s2.ttl`, `data/s4.web.ttl`).\nBoth are reached through `import.meta.resolve`, never by a path into `node_modules`\nand never by copying a file into this repository.\n\n> **The anatomy-dsl dependency is still a local `file:` link, and that is a finding\n> rather than a choice.** `@canonical/anatomy-dsl@0.5.0` is published, but its tarball\n> ships no `dist/` — `files` lists it and `exports[\".\"]` points at\n> `./dist/esm/index.js`, and neither is in the package — so importing the package root\n> fails with `Cannot find package` and `tsc` reports `TS2307` in every module that\n> imports it. The swap to `\"^0.5.0\"` is one line and is blocked on a `0.5.1` published\n> after a build. `@canonical/token-ontology` is already on its published range.\n\n---\n\n## The anatomies: authored, validated, written\n\nThe anatomies are written by hand, one file per anatomy, from the component's\nimplementation. Reading an implementation and choosing the node, the key and the symbol\nit should bind is judgement, so it happens in the file, under review, rather than in a\nderivation.\n\n```bash\n# The law over the corpus, and the one writer of anatomies/register.yaml and\n# anatomies/census.json.\nbun src/cli.ts anatomies validate [--write-register] [--only <uri>] [--json]\n\n# The law over the authored files, offline, over one tier or over all of them.\nbun src/cli.ts anatomies validate --authored [--tier <name>] [--json]\n\n# The authored files into the document's anatomy_dsl cells. Dry by default.\nbun src/cli.ts anatomies write [--apply] [--only <uri>] [--tier <name>] [--json]\n\n# A snapshot of those cells, put back.\nbun src/cli.ts anatomies restore <snapshot> [--apply] [--json]\n```\n\n`validate` is the gate: every symbol an anatomy binds resolves against the token graph,\nevery `uri:` names a block, every exception carries a register row, and the census's\nfloors hold. `ci.yml`'s `census-drift` job runs it with `--write-register` and diffs\n`anatomies/census.json`.\n\n**The files, and who writes them.**\n\n| File | Writer | What it is |\n|---|---|---|\n| `anatomies/authored/<tier>/<uri>.yaml` | by hand | One anatomy each. Reviewed as files in a pull request, and the text of the file is the text of the `anatomy_dsl` cell the write sends |\n| `anatomies/census.json` | `validate --write-register` | The corpus and its counts. The one committed generated file, and the one thing CI diffs |\n| `anatomies/register.yaml` | `validate --write-register` | Every exception, with its hand-written rationale preserved. **Not committed** — most of its rows today are the parse failures of the retired notation, and they disappear as the anatomies are authored, so the file would land at many times its steady-state size. `readRegister` reads a missing file as an empty register, and the census carries the counts |\n| `anatomies/snapshots/<stamp>-uiBlocks.json` | `write --apply`, `restore --apply` | What every `anatomy_dsl` cell said before the run touched it. Gitignored: a recovery artefact of one run against one document |\n\nNothing here writes `data/`, which is the Coda pull sync's alone, and nothing here\nwrites `anatomies/authored/`.\n\n**The write, in the order it is meant to be run.** `anatomies write` is dry by\ndefault: it reads the authored files, runs the law over them, reads the live\n`uiBlocks` table and prints the plan — how many files were read, how many cells\nalready hold theirs, which cells would change, and any file whose `uri` names no row.\nRead that, then write one anatomy as a canary with `--only <uri>` and look at the cell\nin the document, and only then let the rest follow.\n\n```bash\nbun src/cli.ts anatomies write                                    # the plan\nbun src/cli.ts anatomies write --only global.component.button --apply   # the canary\nbun src/cli.ts anatomies write --apply                            # the rest\n```\n\n**A tier at a time, and this round is the top-level tiers.** `anatomies/authored/` is\nsplit by tier, and only the top-level tiers' anatomies are written to the document\nnow: `global`, `apps` and `sites` — of which only `global` and `apps` have anything\nauthored yet, so those two are what this round's write names. The second-level\ntiers — `apps_landscape`, `apps_launchpad`, `apps_lxd`, `apps_anbox` and\n`sites_webcomponentsprototype` — stay\nauthored, reviewed and lawful in their directories, and no cell of theirs is sent.\n`--tier <name>` is what says so: it takes one tier per occurrence, or a\ncomma-separated list, or any mix of the two (`--tier global --tier apps,sites`), and\nit names the directory under `anatomies/authored/`, which is also the first dotted\nsegment of every `uri` in it. A tier that matches no authored file is refused, naming\nthe directory and the tiers it does hold, because a misspelt tier that quietly\nplanned zero cells reads exactly like a corpus already in step. It narrows the plan\nand nothing else: the **law still runs over every authored file**, because a corpus is\nlawful or not as a whole and writing a different anatomy out of it does not make an\nunregistered symbol lawful — so an unlawful file in a tier this round leaves alone\nstill refuses the run. What is narrowed is the plan, and its counts and its header\nline say which tiers they are of (`Anatomy cells — the authored anatomies against\nuiBlocks.anatomy_dsl (tiers: global, apps)`). `--only` composes with it, inside the\ntiers in force. On `validate --authored` the same flag narrows which files are READ,\nso an author with one tier open gets that tier's answer and the others are never\nopened.\n\n```bash\nbun src/cli.ts anatomies validate --authored --tier global   # one tier's law\nbun src/cli.ts anatomies write --tier global,apps            # the plan for this round\nbun src/cli.ts anatomies write --tier global,apps --apply    # and the write\n```\n\n`--apply` is refused, with the reason named, when `CI` is set (the write is an act\nwith a human reading the plan, never a pipeline step), when `CODA_WRITE_TOKEN` is\nunset, when the law reports a finding (a warning prints and the run proceeds), when an\nauthored file names no row in the document, and when the plan is empty. When every\ngate is open it writes `anatomies/snapshots/<stamp>-uiBlocks.json` — every live row's\nrow id, `uri` and cell — **before** its first write, then updates the cells one call\nat a time, then re-reads and checks that every cell it wrote reads back as its file.\nCoda answers 202 and queues a write, so that re-read is the only thing standing\nbetween a write it silently dropped and a run that claims success.\n\n**Where it writes comes from `source.json`, and nowhere else.** The root\nconfiguration already says all four things the write needs, and they are read through\nthe same `validateConfig` every other command reads it through: the document id, the\n`uiBlocks` table id under `extract.tables`, the column that carries the anatomy — the\n`@context` key mapped to `ds:anatomyDsl` in `transform.tables.uiBlocks` — and the\ncolumn a row's subject is built from, which is the placeholder in that table's\n`uriTemplate`. So the write plans against the same table and the same cell the pull\nsync reads, by construction, and a rename in the document is one edit rather than two.\nColumn ids are learned at run time from the table itself, because a cell keyed by\ndisplay name is accepted with a 202 and changes nothing.\n\n`anatomies restore <snapshot>` is the other half: it plans the cells that differ from\na snapshot, behind the same gates, and takes a fresh snapshot of its own before it\nwrites — a restore is a write too, and restoring the wrong file has to be undoable.\nIt only ever writes the `anatomy_dsl` column, and it never creates a row: the roster\nof blocks is the pull sync's.\n\nThe whole write path — its READS included — runs on `CODA_WRITE_TOKEN`, a write-scoped\ntoken for the one document, kept in the gitignored `.env`. It never touches\n`CODA_API_KEY`, the read-only key CI and the daily sync hold, which is what keeps that\ncredential un-escalatable by any code path that reaches for a write.\n\n---\n\n## Data Pipeline\n\nThe design system data is extracted from Coda and transformed to RDF:\n\n```bash\nbun install\n\n# Create .env with Coda API key\necho \"CODA_API_KEY=your-token\" > .env\n\n# Extract and transform\nbun run ds:list        # List available tables\nbun run ds:extract     # Extract to JSON\nbun run ds:transform   # Transform to JSON-LD/Turtle\n```\n\n---\n\n## Implementation Collector\n\nThe `collect-implementations` script scans codebases for `@implements` annotations and generates RDF linking implementations to their design system specifications.\n\n### Setup\n\n1. Create a `design-system.json` config file in your project root:\n\n```json\n{\n  \"name\": \"my-component-library\",\n  \"platform\": \"react\",\n  \"description\": \"React implementation of the design system\",\n  \"link\": \"https://github.com/org/my-library\",\n  \"documentation\": \"https://docs.example.com/components\",\n  \"tier\": \"ds:global\",\n  \"prefix\": {\n    \"short\": \"ds\",\n    \"namespace\": \"https://ds.canonical.com/\"\n  },\n  \"pattern\": \"src/**/*.tsx\",\n  \"outputDir\": \"data\"\n}\n```\n\n### Configuration Options\n\n| Field | Required | Description |\n|-------|----------|-------------|\n| `name` | Yes | Library identifier (e.g., \"pragma-react\") |\n| `platform` | Yes | Framework/platform (react, vue, angular, etc.) |\n| `description` | No | Human-readable library description |\n| `link` | Yes | Main repository or package URL |\n| `documentation` | No | Documentation URL if different from link |\n| `tier` | No | Design system tier reference (e.g., \"ds:global\") |\n| `prefix.short` | Yes | Namespace prefix used in annotations (e.g., \"ds\") |\n| `prefix.namespace` | Yes | Full namespace URI |\n| `pattern` | Yes | Glob pattern for files to scan |\n| `outputDir` | No | Output directory for .ttl files (default: \"data\") |\n\n### Annotating Components\n\nAdd `@implements` annotations as comments in your component files:\n\n```tsx\n// @implements ds:global.component.button\nexport function Button({ children, ...props }) {\n  return <button {...props}>{children}</button>;\n}\n```\n\nAnnotation formats:\n- Basic: `// @implements ds:global.component.button`\n- With version: `// @implements ds:global.component.button@1.0.0`\n- Draft status: `// @implements ds:global.component.button [draft]`\n\n### Running the Collector\n\nFrom within your project directory (where `design-system.json` is located):\n\n```bash\n# Using bun directly\nbun /path/to/design-system/src/collect-implementations.ts\n\n# Or if installed globally/linked\ncollect-implementations\n```\n\n### Output\n\nThe collector generates two Turtle files in the configured output directory. With the\nconfig and annotation from the sections above, it emits (verbatim, after each file's\n`@prefix` header):\n\n1. **`implementationLibrary.ttl`** - Defines the implementation library under\n   `<namespace>implementation.library.<slug>`:\n   ```turtle\n   ds:implementation.library.my-component-library a ds:ImplementationLibrary;\n       ds:libraryName \"my-component-library\";\n       ds:platform \"react\";\n       ds:link \"https://github.com/org/my-library\";\n       ds:summary \"React implementation of the design system\";\n       ds:documentation \"https://docs.example.com/components\";\n       ds:libraryTier ds:global.\n   ```\n\n2. **`implementationObjects.ttl`** - Attaches each annotated file to the library as\n   a blank-node `ds:ImplementationObject` (`ds:headLink` carries the file's relative\n   path):\n   ```turtle\n   ds:implementation.library.my-component-library ds:hasImplementation [\n           a ds:ImplementationObject;\n           ds:implementsBlock ds:global.component.button;\n           ds:headLink \"src/components/Button.tsx\"\n       ].\n   ```\n\n### Example Workflow\n\n```bash\n# 1. Navigate to your component library\ncd my-react-library\n\n# 2. Add annotations to components\necho '// @implements ds:global.component.button' >> src/Button.tsx\n\n# 3. Run the collector\nbun ~/code/cn/design-system/src/collect-implementations.ts\n\n# Output:\n# Scanning src/**/*.tsx for @implements annotations...\n# Found 1 valid implementation(s):\n#   - ds:global.component.button\n# Written: data/implementationLibrary.ttl\n# Written: data/implementationObjects.ttl\n# Done!\n```\n\n---\n\n## CI: Automated Coda Sync\n\nTwo GitHub Actions workflows keep the design system data in sync with Coda:\n\n- **Scheduled** — runs daily at 06:00 UTC\n- **Manual** — trigger from the Actions tab via \"Run workflow\"\n\nBoth run `bun run build` (extract + transform) and commit any changes to `data/`.\n\n### Fail-closed guards\n\n`data/` is fully regenerated on every sync, so a broken extract (expired API\ntoken, renamed grid, partial API response) could silently destroy committed\nspec data. Five independent layers prevent that.\n\nThey divide the work along one line: **a row that asserts nothing is skipped;\na row that asserts something but cannot be emitted fails the sync.** A row\nwith no name is not a thing yet — every Coda grid accumulates such rows,\nbecause clicking into the last row of a grid creates one — and halting the\npipeline over it costs a human deletion to clear. A row that carries a name is\nsomething the document says exists, so losing it must be loud.\n\n1. **Expected-table manifest** — the transform derives the set of tables it\n   expects from `source.json` (outputs, references, and `@inline` embeds) and\n   hard-fails if any is missing from the extract\n   (`src/transform/expectedTables.ts`).\n2. **Delta guards** — the new dataset is staged in a temp directory and\n   compared against the committed `data/` *before* anything is deleted. The\n   transform aborts when a non-empty table yields zero subjects, the subject\n   count drops >10%, any tier file disappears, or the triple count drops >5%\n   (`src/transform/deltaGuards.ts`, `src/transform/collectDataMetrics.ts`).\n3. **Identity filters** — each table declares, in `source.json`, the column\n   that carries a row's identity (`rowFilter.nonEmpty`). A row whose identity\n   column is empty is excluded before transformation: it is not a subject and\n   never becomes one, so it can neither produce a degenerate IRI nor trip the\n   guard below. The count of excluded rows is reported on every sync and\n   appears in the job summary, so blanks stay visible without ever being\n   fatal (`src/transform/rowFilter.ts`,\n   `src/transform/reportFilteredRows.ts`). Deleting them upstream is optional\n   tidying. Every configured table must declare such a filter, which\n   `src/transform/identityFilter.tests.ts` enforces: a table without one is a\n   latent outage.\n4. **Malformed-row guard** — a row whose `uri` is *present but degenerate*\n   (a blank or dangling upstream reference leaves empty dot-separated\n   segments, e.g. `ds:global..`) cannot be emitted as valid Turtle, so the\n   transform drops it and its subject silently disappears from `data/`. The\n   threshold is **zero**: one such row fails the sync, naming the offending\n   URI and its table, so the defect is fixed at the source instead of\n   surfacing later as an unexplained deletion count\n   (`src/transform/deltaGuards.ts`, `src/transform/classifySubjectUri.ts`).\n   A row with **no** `uri` at all is a routine skip (a trailing blank grid\n   row) and is not counted. Its sibling, the **untypable-row guard**, covers\n   the other way a named row vanishes: its identity resolves but its `type`\n   column is empty or dangling, so it cannot be given an RDF class. Same\n   threshold of zero, same escape hatch. Before it existed such a row was\n   dropped in total silence — no warning, no count, no failure.\n5. **Workflow content-loss guard** — after regeneration, the sync workflow\n   checks the staged git diff and refuses to commit when the sync *loses*\n   committed content: deletions that nothing added back, measured as **net\n   loss** (deleted − added) against a share of the committed corpus, with an\n   absolute ceiling as a catastrophic backstop\n   (`src/scripts/evaluateDataDeletion.ts`). Content rewritten in place —\n   large deletions with comparable additions, which is what re-derived\n   authored literals look like — passes; content that simply disappears does\n   not. Being a proportion, it does not need raising as the corpus grows.\n\nOn any guard failure the run fails without committing, the job summary names\n*which* guard tripped and what to fix, and an issue is opened/annotated with\nthe same text.\n\n#### Escape hatches\n\nBoth loss-shaped guards are fail-closed by default and share one escape\nhatch; the two row-level guards share a second one, so that allowing an\nintentional mass deletion does not also wave through rows the source is\nlosing by accident. Identity filters have no escape hatch and need none —\nthey never fail a sync.\n\n| Situation | Manual workflow input | Environment variable |\n| --- | --- | --- |\n| Intentional large deletion (a planned cleanup in Coda) | `allow_shrink` | `SYNC_ALLOW_SHRINK=1` |\n| Known-malformed upstream rows that cannot be fixed yet | `allow_malformed_rows` | `SYNC_ALLOW_MALFORMED_ROWS=1` |\n| Named rows whose `type` cannot be filled in yet | `allow_malformed_rows` | `SYNC_ALLOW_MALFORMED_ROWS=1` |\n\nEither input downgrades its guard to a warning for that run. Locally:\n`SYNC_ALLOW_SHRINK=1 bun run build`. Scheduled runs never set either one.\n\nThe content-loss thresholds can also be overridden per run with\n`SYNC_MAX_NET_LINE_LOSS_RATIO`, `SYNC_MAX_NET_FILE_LOSS_RATIO` and\n`SYNC_MAX_NET_DELETED_LINES`; prefer the escape hatch, which leaves the\ndefaults intact.\n\n### Setting up the two API tokens\n\nThere are two, and the split is the point: CI holds a read-only token, and the token\nthat can write is never in CI.\n\n**`CODA_API_KEY` — read only, held by CI.** Used by `ds:extract`, `ds:list`,\n`ds:transform` and the daily pull sync.\n\n1. Go to <https://coda.io/account>\n2. Scroll to **API settings**\n3. Click **Generate API token**\n4. Name it `ci-access-token`\n5. Add a restriction:\n   - Type: **Doc or table**\n   - Access: **Read only**\n   - Doc ID: the full `_d`-prefixed value from the Coda URL — for example, given `https://coda.io/d/Design-System-Database_dNyzE_TLZDh/`, the ID is `_dNyzE_TLZDh`. Verify by navigating to `https://coda.io/d/_dNyzE_TLZDh`\n6. Copy the token, then in your GitHub repo go to **Settings > Secrets and variables > Actions** and create a secret named `CODA_API_KEY` with the token value\n\n**`CODA_WRITE_TOKEN` — read and write, local only.** Used by `anatomies write` and\n`anatomies restore`, for their reads as well as their writes. The same steps, with\n**Read/Write** access and the same document restriction, and it goes in the gitignored\n`.env` — never in CI, and never in a workflow secret.\n\n> **The API host is the workspace's own**, `https://docs.superhuman.com/apis/v1`, not\n> `coda.io`. The two do not answer for the same state: a read against `coda.io`\n> returns a stale view of this workspace, and a write against it is accepted with a\n> 202 and never applies. `CODA_API_BASE` in `src/providers/CodaProvider.ts` is the one\n> place that says so, and a test asserts it.\n\n---\n\n## Version\n\nThe current version lives in `package.json` — read it there, never from this file.\n\n## References\n\n- [Canonical's Design System: Towards a Design System Ontology](https://discourse.ubuntu.com/t/canonicals-new-design-system-towards-a-design-system-ontology/70367)\n- [Vanilla Framework](https://vanillaframework.io/)\n","readmeFilename":"README.md","homepage":"https://github.com/canonical/pragma-core#readme","repository":{"url":"git+https://github.com/canonical/pragma-core.git","type":"git"},"bugs":{"url":"https://github.com/canonical/pragma-core/issues"}}