diff --git a/.claude-plugin/marketplace.json b/.claude-plugin/marketplace.json index 2f6c0b6..a522798 100644 --- a/.claude-plugin/marketplace.json +++ b/.claude-plugin/marketplace.json @@ -118,6 +118,16 @@ "category": "integrations", "keywords": ["notion", "chatgpt", "cloudflare", "proxy", "agent"] } +, + { + "name": "chittyos-security", + "description": "ChittyOS security review and threat modeling for Cloudflare Workers, MCP boundaries, secrets, data stores, and Workers Builds", + "version": "0.1.0", + "source": "./plugins/chittyos-security", + "strict": false, + "category": "security", + "keywords": ["security", "threat-model", "cloudflare", "workers", "mcp", "secrets", "compliance"] + } , { "name": "neon-mcp", diff --git a/.github/workflows/hydrate-pointers.yml b/.github/workflows/hydrate-pointers.yml index af4c93b..8f7a900 100644 --- a/.github/workflows/hydrate-pointers.yml +++ b/.github/workflows/hydrate-pointers.yml @@ -48,7 +48,7 @@ jobs: with: token: ${{ secrets.GITHUB_TOKEN }} branch: chore/hydrate-pointers-${{ github.run_number }} - base: feat/market-refactor-v2 + base: main title: 'chore(hydrate): refresh pointer-agent content from upstream' body: | Automated hydration via `plugins/chittyagent-dispatch/scripts/hydrate-pointers.sh`. diff --git a/.github/workflows/validate-chittymarket.yml b/.github/workflows/validate-chittymarket.yml index 758f6c9..7bf30be 100644 --- a/.github/workflows/validate-chittymarket.yml +++ b/.github/workflows/validate-chittymarket.yml @@ -13,7 +13,7 @@ on: push: branches: - main - - "feat/**" + workflow_dispatch: # Cancel in-progress runs when a new commit lands on the same PR/branch. concurrency: diff --git a/canonical/.dispatch-state/mcp/neon.json b/canonical/.dispatch-state/mcp/neon.json index 1a451a4..583b8f7 100644 --- a/canonical/.dispatch-state/mcp/neon.json +++ b/canonical/.dispatch-state/mcp/neon.json @@ -1,6 +1,6 @@ { - "canonical_sha": "f5c0015ec224fe474fb90bbd837eb24524572fd7", + "canonical_sha": "b5d6fbc673d84816d8663a351c09b36c92c04d05", "targets": { - "claude-code": "c1b853a0c6f2edcb7119d694133f18982395d64a" + "claude-code": "974b0760edd6142ebb88caacc0a3a094ec896fbb" } } \ No newline at end of file diff --git a/canonical/.dispatch-state/skills/capability-governor.json b/canonical/.dispatch-state/skills/capability-governor.json index e35b892..072e0aa 100644 --- a/canonical/.dispatch-state/skills/capability-governor.json +++ b/canonical/.dispatch-state/skills/capability-governor.json @@ -1,7 +1,8 @@ { - "canonical_sha": "01a2cb0be475030e9aae5ad3c0f46e9621adeb47", + "canonical_sha": "c6d0e09a2fada41945fd8621829024c65462ae17", "targets": { "claude-code": "f1857329abe5a0b616204e24949c84cc9cdb8526", - "codex": "f1857329abe5a0b616204e24949c84cc9cdb8526" + "codex": "f1857329abe5a0b616204e24949c84cc9cdb8526", + "gemini": "f1857329abe5a0b616204e24949c84cc9cdb8526" } } \ No newline at end of file diff --git a/canonical/.dispatch-state/skills/capability-registry-audit.json b/canonical/.dispatch-state/skills/capability-registry-audit.json index 600edfb..5c299c6 100644 --- a/canonical/.dispatch-state/skills/capability-registry-audit.json +++ b/canonical/.dispatch-state/skills/capability-registry-audit.json @@ -1,7 +1,8 @@ { - "canonical_sha": "05ce528e81147fc5c506bbbcb92d99c2642f49c8", + "canonical_sha": "b3e7e91c0273ad11bb07a96d194b3aa9cfecfdf1", "targets": { "claude-code": "efe5f8d43438410b5b88c2690424ef101e68bd5a", - "codex": "efe5f8d43438410b5b88c2690424ef101e68bd5a" + "codex": "efe5f8d43438410b5b88c2690424ef101e68bd5a", + "gemini": "efe5f8d43438410b5b88c2690424ef101e68bd5a" } } \ No newline at end of file diff --git a/canonical/.dispatch-state/skills/cast.json b/canonical/.dispatch-state/skills/cast.json index c8ae681..7f820c3 100644 --- a/canonical/.dispatch-state/skills/cast.json +++ b/canonical/.dispatch-state/skills/cast.json @@ -1,7 +1,8 @@ { - "canonical_sha": "cb887de96770b59c50752b70b2ddead43088a05d", + "canonical_sha": "c846bb18a3f688c5c3af451e7de5988c610e002c", "targets": { "claude-code": "7d71206d677590413441c82c77212b0e50f14404", - "codex": "7d71206d677590413441c82c77212b0e50f14404" + "codex": "7d71206d677590413441c82c77212b0e50f14404", + "gemini": "7d71206d677590413441c82c77212b0e50f14404" } } \ No newline at end of file diff --git a/canonical/.dispatch-state/skills/checkpoint.json b/canonical/.dispatch-state/skills/checkpoint.json index 3cc9954..21fd0f9 100644 --- a/canonical/.dispatch-state/skills/checkpoint.json +++ b/canonical/.dispatch-state/skills/checkpoint.json @@ -1,7 +1,8 @@ { - "canonical_sha": "5d82d1d35da6c829d42bbe996426c31397237e4f", + "canonical_sha": "61052485060d54fb8628a04b6f85c48e6e357e59", "targets": { "claude-code": "fea910cc80125d94a762b3c4e173a5dfd1e67fb9", - "codex": "fea910cc80125d94a762b3c4e173a5dfd1e67fb9" + "codex": "fea910cc80125d94a762b3c4e173a5dfd1e67fb9", + "gemini": "fea910cc80125d94a762b3c4e173a5dfd1e67fb9" } } \ No newline at end of file diff --git a/canonical/.dispatch-state/skills/chico.json b/canonical/.dispatch-state/skills/chico.json index c0b6f58..73e591d 100644 --- a/canonical/.dispatch-state/skills/chico.json +++ b/canonical/.dispatch-state/skills/chico.json @@ -1,7 +1,8 @@ { - "canonical_sha": "66fe5c09e5db5b50fa856643903fa6a9f3a2a1b1", + "canonical_sha": "89d48b7218c4b9006b2f5316aad81d8d82c7d1ec", "targets": { - "claude-code": "d3b81f3bf6b468704d264d8fe3ba24276fce2864", - "codex": "d3b81f3bf6b468704d264d8fe3ba24276fce2864" + "claude-code": "9cd43af7b320bebdf12f657917d52cb1e7f7ddad", + "codex": "9cd43af7b320bebdf12f657917d52cb1e7f7ddad", + "gemini": "9cd43af7b320bebdf12f657917d52cb1e7f7ddad" } } \ No newline at end of file diff --git a/canonical/.dispatch-state/skills/chitty-autonomy-affirm.json b/canonical/.dispatch-state/skills/chitty-autonomy-affirm.json index 7cc8b2f..1ede8f2 100644 --- a/canonical/.dispatch-state/skills/chitty-autonomy-affirm.json +++ b/canonical/.dispatch-state/skills/chitty-autonomy-affirm.json @@ -1,7 +1,8 @@ { - "canonical_sha": "2571bbe411f1fdd56f12545c2e919a02b533be35", + "canonical_sha": "7b8f477a09225cc0014bb749ca4d1d3555c78c8f", "targets": { "claude-code": "451e0d03540f320c67dfaf524c7436adb6fec787", - "codex": "451e0d03540f320c67dfaf524c7436adb6fec787" + "codex": "451e0d03540f320c67dfaf524c7436adb6fec787", + "gemini": "451e0d03540f320c67dfaf524c7436adb6fec787" } } \ No newline at end of file diff --git a/canonical/.dispatch-state/skills/chitty-autonomy-cicd.json b/canonical/.dispatch-state/skills/chitty-autonomy-cicd.json index 03e7019..51fc6c9 100644 --- a/canonical/.dispatch-state/skills/chitty-autonomy-cicd.json +++ b/canonical/.dispatch-state/skills/chitty-autonomy-cicd.json @@ -1,7 +1,8 @@ { - "canonical_sha": "5ac95fa19dcd8f92e91c7b05ccb91f6140a7dafe", + "canonical_sha": "c12a2bf18c3c2d2b46388bb2b2f9fe4a727f40be", "targets": { "claude-code": "c0965b185ac29bd16fb0749245252729f8b689b1", - "codex": "c0965b185ac29bd16fb0749245252729f8b689b1" + "codex": "c0965b185ac29bd16fb0749245252729f8b689b1", + "gemini": "c0965b185ac29bd16fb0749245252729f8b689b1" } } \ No newline at end of file diff --git a/canonical/.dispatch-state/skills/chitty-autonomy-discover.json b/canonical/.dispatch-state/skills/chitty-autonomy-discover.json index 1a59495..ebb0669 100644 --- a/canonical/.dispatch-state/skills/chitty-autonomy-discover.json +++ b/canonical/.dispatch-state/skills/chitty-autonomy-discover.json @@ -1,7 +1,8 @@ { - "canonical_sha": "b314ec6e1a79645fcf2bcdffdd67968dbf8cde87", + "canonical_sha": "0ea1eedf80addd002783a081c29c08400f45ad40", "targets": { "claude-code": "5806ccf4ace2df5ca1f4bac24b603015912e736c", - "codex": "5806ccf4ace2df5ca1f4bac24b603015912e736c" + "codex": "5806ccf4ace2df5ca1f4bac24b603015912e736c", + "gemini": "5806ccf4ace2df5ca1f4bac24b603015912e736c" } } \ No newline at end of file diff --git a/canonical/.dispatch-state/skills/chitty-autonomy-generate.json b/canonical/.dispatch-state/skills/chitty-autonomy-generate.json index 850b1f3..5aeaf0d 100644 --- a/canonical/.dispatch-state/skills/chitty-autonomy-generate.json +++ b/canonical/.dispatch-state/skills/chitty-autonomy-generate.json @@ -1,7 +1,8 @@ { - "canonical_sha": "fbf654d87f0267ddfab661f128cdc5c4a47f639c", + "canonical_sha": "02f507144d11bd8c46aeba900f046bd373b7c460", "targets": { "claude-code": "9895f26780112c7d9005d18ebcd8abd6b0dc7fda", - "codex": "9895f26780112c7d9005d18ebcd8abd6b0dc7fda" + "codex": "9895f26780112c7d9005d18ebcd8abd6b0dc7fda", + "gemini": "9895f26780112c7d9005d18ebcd8abd6b0dc7fda" } } \ No newline at end of file diff --git a/canonical/.dispatch-state/skills/chitty-autonomy-implement.json b/canonical/.dispatch-state/skills/chitty-autonomy-implement.json index 578dbdf..9fdd8e0 100644 --- a/canonical/.dispatch-state/skills/chitty-autonomy-implement.json +++ b/canonical/.dispatch-state/skills/chitty-autonomy-implement.json @@ -1,7 +1,8 @@ { - "canonical_sha": "f797fa6033e1dbb75649246d03db01f58dff3972", + "canonical_sha": "722513ebc2630d5e740cf4ddfb67f5f2403f916c", "targets": { "claude-code": "02d03163fa6bee00fefe3e8e2b2260e1a93d9e1b", - "codex": "02d03163fa6bee00fefe3e8e2b2260e1a93d9e1b" + "codex": "02d03163fa6bee00fefe3e8e2b2260e1a93d9e1b", + "gemini": "02d03163fa6bee00fefe3e8e2b2260e1a93d9e1b" } } \ No newline at end of file diff --git a/canonical/.dispatch-state/skills/chitty-autonomy-plan.json b/canonical/.dispatch-state/skills/chitty-autonomy-plan.json index 69b71d7..e46595f 100644 --- a/canonical/.dispatch-state/skills/chitty-autonomy-plan.json +++ b/canonical/.dispatch-state/skills/chitty-autonomy-plan.json @@ -1,7 +1,8 @@ { - "canonical_sha": "f5765aa37c63c3224b25a080087bfaf4eaa278a7", + "canonical_sha": "395784b09e4059b4ee001fee24450e63334943ed", "targets": { "claude-code": "e9eafbd9febec329ce1a661cef726e2b30ad03cf", - "codex": "e9eafbd9febec329ce1a661cef726e2b30ad03cf" + "codex": "e9eafbd9febec329ce1a661cef726e2b30ad03cf", + "gemini": "e9eafbd9febec329ce1a661cef726e2b30ad03cf" } } \ No newline at end of file diff --git a/canonical/.dispatch-state/skills/chitty-autonomy-ship.json b/canonical/.dispatch-state/skills/chitty-autonomy-ship.json index f5aa227..4152b4e 100644 --- a/canonical/.dispatch-state/skills/chitty-autonomy-ship.json +++ b/canonical/.dispatch-state/skills/chitty-autonomy-ship.json @@ -1,7 +1,8 @@ { - "canonical_sha": "7b76e813700e2f1a9707dbf688ec797786f72935", + "canonical_sha": "38e53f22bb238fe5860f89f524ea6c64095db100", "targets": { "claude-code": "9bbfa55fc9b8af7b313e223c2f2bdd542c35ea02", - "codex": "9bbfa55fc9b8af7b313e223c2f2bdd542c35ea02" + "codex": "9bbfa55fc9b8af7b313e223c2f2bdd542c35ea02", + "gemini": "9bbfa55fc9b8af7b313e223c2f2bdd542c35ea02" } } \ No newline at end of file diff --git a/canonical/.dispatch-state/skills/chitty-autonomy-tidy.json b/canonical/.dispatch-state/skills/chitty-autonomy-tidy.json index 520199e..bc8144d 100644 --- a/canonical/.dispatch-state/skills/chitty-autonomy-tidy.json +++ b/canonical/.dispatch-state/skills/chitty-autonomy-tidy.json @@ -1,7 +1,8 @@ { - "canonical_sha": "de6bb4be4e7d90520c9a5fcc0f15157fde5644fa", + "canonical_sha": "35b8f0a40faf29ee63702da4003040abf481404b", "targets": { "claude-code": "51f1d7f2b22c65ded4ba83447eb798063493bf08", - "codex": "51f1d7f2b22c65ded4ba83447eb798063493bf08" + "codex": "51f1d7f2b22c65ded4ba83447eb798063493bf08", + "gemini": "51f1d7f2b22c65ded4ba83447eb798063493bf08" } } \ No newline at end of file diff --git a/canonical/.dispatch-state/skills/chitty-autonomy.json b/canonical/.dispatch-state/skills/chitty-autonomy.json index c01a1b0..fc17b4b 100644 --- a/canonical/.dispatch-state/skills/chitty-autonomy.json +++ b/canonical/.dispatch-state/skills/chitty-autonomy.json @@ -1,7 +1,8 @@ { - "canonical_sha": "21531184cbcae26224e09da6a42fda6324a51151", + "canonical_sha": "7b6feb1467fe9a85a91e4f49836f14c85a9edf3f", "targets": { "claude-code": "a6bde1517601d7f11267c0605cff7c030afaf949", - "codex": "a6bde1517601d7f11267c0605cff7c030afaf949" + "codex": "a6bde1517601d7f11267c0605cff7c030afaf949", + "gemini": "a6bde1517601d7f11267c0605cff7c030afaf949" } } \ No newline at end of file diff --git a/canonical/.dispatch-state/skills/chitty-cleanup.json b/canonical/.dispatch-state/skills/chitty-cleanup.json index 81808fc..dc8d3c9 100644 --- a/canonical/.dispatch-state/skills/chitty-cleanup.json +++ b/canonical/.dispatch-state/skills/chitty-cleanup.json @@ -1,7 +1,8 @@ { - "canonical_sha": "44bb4af3a9f1f4e4dcca8307990531be8706d446", + "canonical_sha": "fcedb0e38b9fa1c0424e31f83d65d6dcc24c617d", "targets": { "claude-code": "3651c96751b394efa38233f6787e1a434eff4a40", - "codex": "3651c96751b394efa38233f6787e1a434eff4a40" + "codex": "3651c96751b394efa38233f6787e1a434eff4a40", + "gemini": "3651c96751b394efa38233f6787e1a434eff4a40" } } \ No newline at end of file diff --git a/canonical/.dispatch-state/skills/chitty-deploy.json b/canonical/.dispatch-state/skills/chitty-deploy.json index cdc60a7..4f50fbd 100644 --- a/canonical/.dispatch-state/skills/chitty-deploy.json +++ b/canonical/.dispatch-state/skills/chitty-deploy.json @@ -1,7 +1,8 @@ { - "canonical_sha": "bdba52f183d65822c4b3f92d5cff55aab8bf1f89", + "canonical_sha": "474f40700272b03568e2e4cb7493eab209505b8f", "targets": { "claude-code": "8a4ec7951997c55afc3e09463f18a8868e8ecc32", - "codex": "8a4ec7951997c55afc3e09463f18a8868e8ecc32" + "codex": "8a4ec7951997c55afc3e09463f18a8868e8ecc32", + "gemini": "8a4ec7951997c55afc3e09463f18a8868e8ecc32" } } \ No newline at end of file diff --git a/canonical/.dispatch-state/skills/chitty-health.json b/canonical/.dispatch-state/skills/chitty-health.json index 2f09e09..cdb0d45 100644 --- a/canonical/.dispatch-state/skills/chitty-health.json +++ b/canonical/.dispatch-state/skills/chitty-health.json @@ -1,7 +1,8 @@ { - "canonical_sha": "d643cf36511977076e321ef9c52901ea37c65e34", + "canonical_sha": "a918c417648d7f0d9b27c4e4d977eb9b695ad5dd", "targets": { "claude-code": "354c63083a738b410d8fdc8933063060aed1550d", - "codex": "354c63083a738b410d8fdc8933063060aed1550d" + "codex": "354c63083a738b410d8fdc8933063060aed1550d", + "gemini": "354c63083a738b410d8fdc8933063060aed1550d" } } \ No newline at end of file diff --git a/canonical/.dispatch-state/skills/chitty-pipelines.json b/canonical/.dispatch-state/skills/chitty-pipelines.json index e419cd6..b7133f1 100644 --- a/canonical/.dispatch-state/skills/chitty-pipelines.json +++ b/canonical/.dispatch-state/skills/chitty-pipelines.json @@ -1,7 +1,8 @@ { - "canonical_sha": "5a118876968ebbdfa0a654f5c5b8992697568aa5", + "canonical_sha": "c5a780be6622a3783b47250e5d4acd4aac58c833", "targets": { "claude-code": "7360e9b6e5b0eacfeb6d07cabb0206edf19c6b48", - "codex": "7360e9b6e5b0eacfeb6d07cabb0206edf19c6b48" + "codex": "7360e9b6e5b0eacfeb6d07cabb0206edf19c6b48", + "gemini": "7360e9b6e5b0eacfeb6d07cabb0206edf19c6b48" } } \ No newline at end of file diff --git a/canonical/.dispatch-state/skills/chitty-registry.json b/canonical/.dispatch-state/skills/chitty-registry.json index dfbb4be..e6bd482 100644 --- a/canonical/.dispatch-state/skills/chitty-registry.json +++ b/canonical/.dispatch-state/skills/chitty-registry.json @@ -1,7 +1,8 @@ { - "canonical_sha": "f2be51e6c0bc152dbcf0ed98b200beee82082c6a", + "canonical_sha": "88e9a3d22de6f9dfdb71f13d802a053e78ee25ff", "targets": { "claude-code": "5a9a2785eac3328ce8d58d9b08c1b65e1eba466c", - "codex": "5a9a2785eac3328ce8d58d9b08c1b65e1eba466c" + "codex": "5a9a2785eac3328ce8d58d9b08c1b65e1eba466c", + "gemini": "5a9a2785eac3328ce8d58d9b08c1b65e1eba466c" } } \ No newline at end of file diff --git a/canonical/.dispatch-state/skills/chittycontext.json b/canonical/.dispatch-state/skills/chittycontext.json index 3bc5458..22df67c 100644 --- a/canonical/.dispatch-state/skills/chittycontext.json +++ b/canonical/.dispatch-state/skills/chittycontext.json @@ -1,7 +1,8 @@ { - "canonical_sha": "e2f22c9cf29612a73b8148d91e77a20c278f312c", + "canonical_sha": "52a57b84527add80ddc9c6bc2616718640053ec6", "targets": { "claude-code": "bc88b597edffacca2f452d9f56458bba73958fac", - "codex": "bc88b597edffacca2f452d9f56458bba73958fac" + "codex": "bc88b597edffacca2f452d9f56458bba73958fac", + "gemini": "bc88b597edffacca2f452d9f56458bba73958fac" } } \ No newline at end of file diff --git a/canonical/.dispatch-state/skills/chittygws.json b/canonical/.dispatch-state/skills/chittygws.json index 44c6884..bdc1b13 100644 --- a/canonical/.dispatch-state/skills/chittygws.json +++ b/canonical/.dispatch-state/skills/chittygws.json @@ -1,7 +1,8 @@ { - "canonical_sha": "7648ef6e955ee5e28d38c2c3205841dde4b5f211", + "canonical_sha": "0aba1b0511566fb93621c1d94458480154cebbca", "targets": { "claude-code": "5149802a8657bbdcd7d3a11a95bb79c472e5e8a7", - "codex": "5149802a8657bbdcd7d3a11a95bb79c472e5e8a7" + "codex": "5149802a8657bbdcd7d3a11a95bb79c472e5e8a7", + "gemini": "5149802a8657bbdcd7d3a11a95bb79c472e5e8a7" } } \ No newline at end of file diff --git a/canonical/.dispatch-state/skills/chittyos-compliance.json b/canonical/.dispatch-state/skills/chittyos-compliance.json index 54a553e..0f1e318 100644 --- a/canonical/.dispatch-state/skills/chittyos-compliance.json +++ b/canonical/.dispatch-state/skills/chittyos-compliance.json @@ -1,7 +1,8 @@ { - "canonical_sha": "0df975780caecd37533de6d897339c211bec4bda", + "canonical_sha": "26742148b335dde211b0040b7c041145b6f93310", "targets": { "claude-code": "666445c4ec6c9c3d024397d4328bde0a8c9127ee", - "codex": "666445c4ec6c9c3d024397d4328bde0a8c9127ee" + "codex": "666445c4ec6c9c3d024397d4328bde0a8c9127ee", + "gemini": "666445c4ec6c9c3d024397d4328bde0a8c9127ee" } } \ No newline at end of file diff --git a/canonical/.dispatch-state/skills/chittyos-security-review.json b/canonical/.dispatch-state/skills/chittyos-security-review.json new file mode 100644 index 0000000..583eb85 --- /dev/null +++ b/canonical/.dispatch-state/skills/chittyos-security-review.json @@ -0,0 +1,8 @@ +{ + "canonical_sha": "0a53a4fc386b30b14910a741355b252256253709", + "targets": { + "claude-code": "bd4a9282b20a6b81e4930c3f33a8d5360ad603ea", + "codex": "bd4a9282b20a6b81e4930c3f33a8d5360ad603ea", + "gemini": "bd4a9282b20a6b81e4930c3f33a8d5360ad603ea" + } +} \ No newline at end of file diff --git a/canonical/.dispatch-state/skills/chittyos-threat-model.json b/canonical/.dispatch-state/skills/chittyos-threat-model.json new file mode 100644 index 0000000..dfa5d30 --- /dev/null +++ b/canonical/.dispatch-state/skills/chittyos-threat-model.json @@ -0,0 +1,8 @@ +{ + "canonical_sha": "43b66d7bb6b03f20016d924d4815d108e0c5a1d8", + "targets": { + "claude-code": "0f98cef956111e7756ea311a729ec24c74370ec4", + "codex": "0f98cef956111e7756ea311a729ec24c74370ec4", + "gemini": "0f98cef956111e7756ea311a729ec24c74370ec4" + } +} \ No newline at end of file diff --git a/canonical/.dispatch-state/skills/chittyxl.json b/canonical/.dispatch-state/skills/chittyxl.json index c2d8930..45bc5fb 100644 --- a/canonical/.dispatch-state/skills/chittyxl.json +++ b/canonical/.dispatch-state/skills/chittyxl.json @@ -1,7 +1,8 @@ { - "canonical_sha": "8ffecbc15c0d1823626259d478bef93300508b55", + "canonical_sha": "be441520f5e2345549ed64ae9d854152f48536e6", "targets": { "claude-code": "b96539f72481889fd2e7554d23ecf6b8825a8b00", - "codex": "b96539f72481889fd2e7554d23ecf6b8825a8b00" + "codex": "b96539f72481889fd2e7554d23ecf6b8825a8b00", + "gemini": "b96539f72481889fd2e7554d23ecf6b8825a8b00" } } \ No newline at end of file diff --git a/canonical/.dispatch-state/skills/cli-surface-projection.json b/canonical/.dispatch-state/skills/cli-surface-projection.json index 731046e..f8d3048 100644 --- a/canonical/.dispatch-state/skills/cli-surface-projection.json +++ b/canonical/.dispatch-state/skills/cli-surface-projection.json @@ -1,7 +1,8 @@ { - "canonical_sha": "1ab5e0b485ce4a373abbd40c531c520ef79650c2", + "canonical_sha": "9d92e2000c1ad0b4c1552cc52e880cc1a7a99444", "targets": { "claude-code": "c2e82cfa821dd5c6d8f532e246f5e84c7b313022", - "codex": "c2e82cfa821dd5c6d8f532e246f5e84c7b313022" + "codex": "c2e82cfa821dd5c6d8f532e246f5e84c7b313022", + "gemini": "c2e82cfa821dd5c6d8f532e246f5e84c7b313022" } } \ No newline at end of file diff --git a/canonical/.dispatch-state/skills/cross-surface-hotloading.json b/canonical/.dispatch-state/skills/cross-surface-hotloading.json index 688945f..1f28ab6 100644 --- a/canonical/.dispatch-state/skills/cross-surface-hotloading.json +++ b/canonical/.dispatch-state/skills/cross-surface-hotloading.json @@ -1,7 +1,8 @@ { - "canonical_sha": "d824cb4d4e21064bff409e46faf112b8b57c2860", + "canonical_sha": "390bef4eca879f0ecf532a2f39d5dbe12edd083b", "targets": { "claude-code": "5bfefe06a20166bca8125eb1ce7eaebbc03e08f7", - "codex": "5bfefe06a20166bca8125eb1ce7eaebbc03e08f7" + "codex": "5bfefe06a20166bca8125eb1ce7eaebbc03e08f7", + "gemini": "5bfefe06a20166bca8125eb1ce7eaebbc03e08f7" } } \ No newline at end of file diff --git a/canonical/.dispatch-state/skills/dispute.json b/canonical/.dispatch-state/skills/dispute.json index e86da22..693ce11 100644 --- a/canonical/.dispatch-state/skills/dispute.json +++ b/canonical/.dispatch-state/skills/dispute.json @@ -1,7 +1,8 @@ { - "canonical_sha": "958b3110cbb2304f129a919140e3ca0942a035d0", + "canonical_sha": "6745ccd7d75d23907a89528ddcbca763c7d52fc8", "targets": { "claude-code": "a5d24f8f37b5a025eee2d0d034e2651c91f9fe24", - "codex": "a5d24f8f37b5a025eee2d0d034e2651c91f9fe24" + "codex": "a5d24f8f37b5a025eee2d0d034e2651c91f9fe24", + "gemini": "a5d24f8f37b5a025eee2d0d034e2651c91f9fe24" } } \ No newline at end of file diff --git a/canonical/.dispatch-state/skills/docket.json b/canonical/.dispatch-state/skills/docket.json index b400d2d..10e1dab 100644 --- a/canonical/.dispatch-state/skills/docket.json +++ b/canonical/.dispatch-state/skills/docket.json @@ -1,7 +1,8 @@ { - "canonical_sha": "f9347bec540c2ba29bbb3eee38c5f4e85ce2257e", + "canonical_sha": "eb03e39f363bdf8b953d1ee632ff728492a6ae4d", "targets": { "claude-code": "803111bcb7aebebd0dc3e68cca383742ee815101", - "codex": "803111bcb7aebebd0dc3e68cca383742ee815101" + "codex": "803111bcb7aebebd0dc3e68cca383742ee815101", + "gemini": "803111bcb7aebebd0dc3e68cca383742ee815101" } } \ No newline at end of file diff --git a/canonical/.dispatch-state/skills/evidence-collect.json b/canonical/.dispatch-state/skills/evidence-collect.json index bfa5786..e80b327 100644 --- a/canonical/.dispatch-state/skills/evidence-collect.json +++ b/canonical/.dispatch-state/skills/evidence-collect.json @@ -1,7 +1,8 @@ { - "canonical_sha": "bba0c7408db60afa353053e543b959c89c2f1342", + "canonical_sha": "a0fa0eee367aa12522b647b3aa7c67cf800b777b", "targets": { "claude-code": "24083a98e7cdfdd03807a0b420a13da363955612", - "codex": "24083a98e7cdfdd03807a0b420a13da363955612" + "codex": "24083a98e7cdfdd03807a0b420a13da363955612", + "gemini": "24083a98e7cdfdd03807a0b420a13da363955612" } } \ No newline at end of file diff --git a/canonical/.dispatch-state/skills/evidence-egress.json b/canonical/.dispatch-state/skills/evidence-egress.json index 9939a77..9f3daa7 100644 --- a/canonical/.dispatch-state/skills/evidence-egress.json +++ b/canonical/.dispatch-state/skills/evidence-egress.json @@ -1,7 +1,8 @@ { - "canonical_sha": "dc45e1f9169b3b5f693c5bff6a92065645df763f", + "canonical_sha": "590cc536b6e9af9c5f8f4a74fe90155d1777efc8", "targets": { "claude-code": "0dd1eb67a4e434fef4c0f7de8ed548aad7cceeff", - "codex": "0dd1eb67a4e434fef4c0f7de8ed548aad7cceeff" + "codex": "0dd1eb67a4e434fef4c0f7de8ed548aad7cceeff", + "gemini": "0dd1eb67a4e434fef4c0f7de8ed548aad7cceeff" } } \ No newline at end of file diff --git a/canonical/.dispatch-state/skills/fact-governance.json b/canonical/.dispatch-state/skills/fact-governance.json index 7c2a915..75ddbf1 100644 --- a/canonical/.dispatch-state/skills/fact-governance.json +++ b/canonical/.dispatch-state/skills/fact-governance.json @@ -1,7 +1,8 @@ { - "canonical_sha": "cd490449eb5d8f24901c922c1cab34a63e7667f7", + "canonical_sha": "345de4ebf9da0d1d4f3db846b88fce516271e13b", "targets": { "claude-code": "8f82ae28aece7d3f0a0da63824287469743d697a", - "codex": "8f82ae28aece7d3f0a0da63824287469743d697a" + "codex": "8f82ae28aece7d3f0a0da63824287469743d697a", + "gemini": "8f82ae28aece7d3f0a0da63824287469743d697a" } } \ No newline at end of file diff --git a/canonical/.dispatch-state/skills/goal-creator.json b/canonical/.dispatch-state/skills/goal-creator.json index db0b862..e471112 100644 --- a/canonical/.dispatch-state/skills/goal-creator.json +++ b/canonical/.dispatch-state/skills/goal-creator.json @@ -1,7 +1,8 @@ { - "canonical_sha": "9d338d2b62993d3e5482e1e4d6be5d1c127e6e7a", + "canonical_sha": "f590edb268efeb7769c9ab1bb10d750e75027e36", "targets": { "claude-code": "3b402d1f84847234405a2b881887bc2447c3fefc", - "codex": "3b402d1f84847234405a2b881887bc2447c3fefc" + "codex": "3b402d1f84847234405a2b881887bc2447c3fefc", + "gemini": "3b402d1f84847234405a2b881887bc2447c3fefc" } } \ No newline at end of file diff --git a/canonical/.dispatch-state/skills/hygiene.json b/canonical/.dispatch-state/skills/hygiene.json index 4458f1a..5846d56 100644 --- a/canonical/.dispatch-state/skills/hygiene.json +++ b/canonical/.dispatch-state/skills/hygiene.json @@ -1,7 +1,8 @@ { - "canonical_sha": "b46176075c1895f6cf4b6e67e925a37029b1e209", + "canonical_sha": "bf9c1be89516d9c4f2a9b1d6b6c579441d8a1c8b", "targets": { "claude-code": "96af3ed251017dbb6a19e9da615fa79d3422dc0f", - "codex": "96af3ed251017dbb6a19e9da615fa79d3422dc0f" + "codex": "96af3ed251017dbb6a19e9da615fa79d3422dc0f", + "gemini": "96af3ed251017dbb6a19e9da615fa79d3422dc0f" } } \ No newline at end of file diff --git a/canonical/.dispatch-state/skills/market.json b/canonical/.dispatch-state/skills/market.json index 46cf0bb..ce8edab 100644 --- a/canonical/.dispatch-state/skills/market.json +++ b/canonical/.dispatch-state/skills/market.json @@ -1,7 +1,8 @@ { - "canonical_sha": "5d00a7f1a794f5ac198214419353761d57492144", + "canonical_sha": "54a61ea1fa814971fcb79d875046ce5f28f51e12", "targets": { "claude-code": "b46a9c0553637a41def363d1590add4fef2dcc50", - "codex": "b46a9c0553637a41def363d1590add4fef2dcc50" + "codex": "b46a9c0553637a41def363d1590add4fef2dcc50", + "gemini": "b46a9c0553637a41def363d1590add4fef2dcc50" } } \ No newline at end of file diff --git a/canonical/.dispatch-state/skills/mcp-tool-calling-rules.json b/canonical/.dispatch-state/skills/mcp-tool-calling-rules.json index 1238082..cc4727a 100644 --- a/canonical/.dispatch-state/skills/mcp-tool-calling-rules.json +++ b/canonical/.dispatch-state/skills/mcp-tool-calling-rules.json @@ -1,7 +1,8 @@ { - "canonical_sha": "35fa2fcab8b07fd3263b3e9a5e7126c2c0d5334f", + "canonical_sha": "fd522fbcc8ec891f20d1cf43456f5e479f5c891c", "targets": { "claude-code": "efc7f43ea4987c4eed8da30da51c2d08b0eff1dc", - "codex": "efc7f43ea4987c4eed8da30da51c2d08b0eff1dc" + "codex": "efc7f43ea4987c4eed8da30da51c2d08b0eff1dc", + "gemini": "efc7f43ea4987c4eed8da30da51c2d08b0eff1dc" } } \ No newline at end of file diff --git a/canonical/.dispatch-state/skills/nb-development-defaults.json b/canonical/.dispatch-state/skills/nb-development-defaults.json index f673f5a..472f321 100644 --- a/canonical/.dispatch-state/skills/nb-development-defaults.json +++ b/canonical/.dispatch-state/skills/nb-development-defaults.json @@ -1,7 +1,8 @@ { - "canonical_sha": "1e034006f94ca1f4bb77a671056bcc1762df584d", + "canonical_sha": "bdaebfe703abb9a68629a245234d4eb0d4fa5b02", "targets": { - "claude-code": "d5626bd2b04ca47a8359487318b3f4f2831110e0", - "codex": "d5626bd2b04ca47a8359487318b3f4f2831110e0" + "claude-code": "56b1aed894386b67d3b1f7531e1fad3c6cc20b6c", + "codex": "56b1aed894386b67d3b1f7531e1fad3c6cc20b6c", + "gemini": "56b1aed894386b67d3b1f7531e1fad3c6cc20b6c" } } \ No newline at end of file diff --git a/canonical/.dispatch-state/skills/nowebmaster-architecture.json b/canonical/.dispatch-state/skills/nowebmaster-architecture.json index c51a18f..9299340 100644 --- a/canonical/.dispatch-state/skills/nowebmaster-architecture.json +++ b/canonical/.dispatch-state/skills/nowebmaster-architecture.json @@ -1,7 +1,8 @@ { - "canonical_sha": "b3d23e995007a7af6557eb5715af93fdcdb6dae3", + "canonical_sha": "16dcc978eaf47d5b502726625fe5cf084934a37d", "targets": { "claude-code": "1771e9684aed8fabd9c879f114183e63dc224faa", - "codex": "1771e9684aed8fabd9c879f114183e63dc224faa" + "codex": "1771e9684aed8fabd9c879f114183e63dc224faa", + "gemini": "1771e9684aed8fabd9c879f114183e63dc224faa" } } \ No newline at end of file diff --git a/canonical/.dispatch-state/skills/retrospect.json b/canonical/.dispatch-state/skills/retrospect.json index d350a6c..30dbab3 100644 --- a/canonical/.dispatch-state/skills/retrospect.json +++ b/canonical/.dispatch-state/skills/retrospect.json @@ -1,7 +1,8 @@ { - "canonical_sha": "4dac129454c6b0395d760fe8488e15c50bf38321", + "canonical_sha": "2237284519b253c3239ae8125f3b4e2aee567773", "targets": { "claude-code": "d8db915c1940b5e728850aab8b18f51983c85c33", - "codex": "d8db915c1940b5e728850aab8b18f51983c85c33" + "codex": "d8db915c1940b5e728850aab8b18f51983c85c33", + "gemini": "d8db915c1940b5e728850aab8b18f51983c85c33" } } \ No newline at end of file diff --git a/canonical/.dispatch-state/skills/skill-creator.json b/canonical/.dispatch-state/skills/skill-creator.json index a3a7763..0ac8c94 100644 --- a/canonical/.dispatch-state/skills/skill-creator.json +++ b/canonical/.dispatch-state/skills/skill-creator.json @@ -1,7 +1,8 @@ { - "canonical_sha": "946713676965d30346196694656507b4c4aa218c", + "canonical_sha": "e882da33777a1996c9df99c8cc4ec3905e292605", "targets": { "claude-code": "2cbbc4cc1a04fc163c56f7afb3af2b8ae853b739", - "codex": "2cbbc4cc1a04fc163c56f7afb3af2b8ae853b739" + "codex": "2cbbc4cc1a04fc163c56f7afb3af2b8ae853b739", + "gemini": "2cbbc4cc1a04fc163c56f7afb3af2b8ae853b739" } } \ No newline at end of file diff --git a/canonical/.dispatch-state/skills/wrangler-audit.json b/canonical/.dispatch-state/skills/wrangler-audit.json index 5eed39c..5df066e 100644 --- a/canonical/.dispatch-state/skills/wrangler-audit.json +++ b/canonical/.dispatch-state/skills/wrangler-audit.json @@ -1,7 +1,8 @@ { - "canonical_sha": "25e0d766eba3c290279d562d7c5378a0e4101eb4", + "canonical_sha": "f0c0ef1d9c01b6c4408bd13c4d597fa2becf7357", "targets": { "claude-code": "6226b5e0cd9f0fd488305814a0e607a98017c849", - "codex": "6226b5e0cd9f0fd488305814a0e607a98017c849" + "codex": "6226b5e0cd9f0fd488305814a0e607a98017c849", + "gemini": "6226b5e0cd9f0fd488305814a0e607a98017c849" } } \ No newline at end of file diff --git a/canonical/mcp/neon.md b/canonical/mcp/neon.md index f5c0015..b5d6fbc 100644 --- a/canonical/mcp/neon.md +++ b/canonical/mcp/neon.md @@ -14,7 +14,7 @@ mcp: command: /bin/sh args: - -lc - - exec npx -y @neondatabase/mcp-server-neon start "$NEON_API_KEY" + - case "$NEON_API_KEY" in ""|*://*) echo "POLICY_BLOCKED_CREDENTIAL_UNRESOLVED: neon-mcp NEON_API_KEY is an unresolved broker reference, not a token. Route through ChittyConnect (/chico). Refusing to start." >&2; exit 78;; esac; exec npx -y @neondatabase/mcp-server-neon start "$NEON_API_KEY" env: NEON_API_KEY: chittysecrets://NEON_API_KEY --- diff --git a/canonical/skills/capability-governor.md b/canonical/skills/capability-governor.md index 01a2cb0..c6d0e09 100644 --- a/canonical/skills/capability-governor.md +++ b/canonical/skills/capability-governor.md @@ -7,6 +7,7 @@ plugin: chittyos-governance runtimes: - claude-code - codex + - gemini classification: - governance - compliance diff --git a/canonical/skills/capability-registry-audit.md b/canonical/skills/capability-registry-audit.md index 05ce528..b3e7e91 100644 --- a/canonical/skills/capability-registry-audit.md +++ b/canonical/skills/capability-registry-audit.md @@ -7,6 +7,7 @@ plugin: chittyos-governance runtimes: - claude-code - codex + - gemini classification: - governance - compliance diff --git a/canonical/skills/cast.md b/canonical/skills/cast.md index cb887de..c846bb1 100644 --- a/canonical/skills/cast.md +++ b/canonical/skills/cast.md @@ -9,6 +9,7 @@ classification: runtimes: - claude-code - codex + - gemini plugin: chittyos-mcp --- diff --git a/canonical/skills/checkpoint.md b/canonical/skills/checkpoint.md index 5d82d1d..6105248 100644 --- a/canonical/skills/checkpoint.md +++ b/canonical/skills/checkpoint.md @@ -9,6 +9,7 @@ classification: runtimes: - claude-code - codex + - gemini plugin: chittyos-core --- diff --git a/canonical/skills/chico.md b/canonical/skills/chico.md index 66fe5c0..89d48b7 100644 --- a/canonical/skills/chico.md +++ b/canonical/skills/chico.md @@ -1,6 +1,12 @@ --- name: chico -description: 'Shortcut to dispatch the ChittyConnect concierge (chittyos-core/chittyconnect-concierge) — the canonical owner of credentials, connections, secret rotation, KV/D1 bindings, and ChittyConnect-side wiring. Triggers on "/chico", "/chico-keys", or when the user wants to invoke the concierge by its nickname. The concierge handles ChittySecrets resolution, wrangler secret put, CF API token rotation, binding restore, deploy-time binding audits, and anything in the credential lane. The operator (user) is OPERATOR ONLY — never asked to paste a secret; route through chico-keys.' +description: >- + Shortcut to dispatch the ChittyConnect concierge + (chittyos-core:chittyagent-connect) — the canonical owner of credentials, + connections, secret rotation, KV/D1 bindings, and ChittyConnect-side wiring. + Triggers on "/chico", "/chico-keys", or when the user wants to invoke the + concierge by its nickname. The operator is OPERATOR ONLY — never asked to + paste a secret; route through chico-keys. canon_uri: chittycanon://core/services/chittymarket#skills/chico kind: skill classification: @@ -9,18 +15,19 @@ classification: runtimes: - claude-code - codex + - gemini plugin: chittyos-core --- # /chico — ChittyConnect Concierge Alias -The user invoked `/chico` to dispatch the **chittyos-core:chittyconnect-concierge** agent (nickname: "chico-keys"). Treat the rest of the user's message as the task brief for the concierge. +The user invoked `/chico` to dispatch the **chittyos-core:chittyagent-connect** agent (nickname: "chico-keys"). Treat the rest of the user's message as the task brief for the concierge. ## What to do 1. Read the user's arguments / message body — that's the brief. 2. Dispatch the concierge via the Task tool with: - - `subagent_type: "chittyos-core:chittyconnect-concierge"` + - `subagent_type: "chittyos-core:chittyagent-connect"` - `description`: a 3-5 word summary of the task - `prompt`: the user's brief, expanded with the standing constraints below if needed - `run_in_background: true` for longer credential/deploy work; foreground for quick lookups @@ -30,11 +37,13 @@ The user invoked `/chico` to dispatch the **chittyos-core:chittyconnect-concierg These are binding for every chico-keys invocation: -- **The operator is OPERATOR ONLY** — never asked to paste/provide/rotate any credential value. If a value is needed, it is resolved through **ChittySecrets** (`secrets.chitty.cc`, fronting the Cloudflare Secrets Store) by the concierge. 1Password / `op` is RETIRED — never invoke it. +- **The operator is OPERATOR ONLY** — never asked to paste/provide/rotate any credential value. If a value is needed, resolve it through the ChittyConnect / ChittySecrets broker lane (concierge's job). Do NOT use `op` / 1Password on this host: it has zero accounts configured (`op account list` returns empty), so every `op read` / `op run` fails. - **Real validation only** — no mocks, no placeholder values, no "would-be" config. Concrete evidence (curl output, deploy version id, audit script result). - **Safe deploy only** — bare `wrangler deploy` is the documented anti-pattern (see chittyconnect#217/#221, chittyentity#324/#315). Always `--env production` (or staging), routed through `safe-deploy.sh` if the worker has one. - **Operator approval required** for: production deploys of new (not yet shipped) code, secret rotations affecting org-wide auth, anything irreversible without rollback. Surface for go/no-go; do not auto-execute. -- **If genuinely blocked** (secret absent from ChittySecrets, CF Access denied, cross-cutting policy) → STOP and file a follow-up issue on the right repo (chittyconnect, chittyentity, etc.). Do NOT route the blocker back to the operator as a credential ask. +- **A non-functional `op` / 1Password lane is an EXPECTED host condition** — never a finding, never a blocker, and never grounds for filing a follow-up issue. Use the broker lane instead. +- **If the broker path is unavailable** (ChittyConnect / ChittySecrets unreachable, unauthenticated, or refusing) → **fail closed and loud**: emit the literal token `POLICY_BLOCKED_CHITTYCONNECT_UNAVAILABLE` in the concierge report so it is greppable, and stop. Never silently fall back to a local credential lane, and never substitute a placeholder value. +- **If genuinely blocked** for any other reason (cross-cutting policy, missing authorization, ambiguous scope) → STOP and file a follow-up issue on the right repo (chittyconnect, chittyentity, etc.). Do NOT route the blocker back to the operator as a credential ask. ## When NOT to use /chico @@ -45,12 +54,12 @@ These are binding for every chico-keys invocation: ## Examples - `/chico restore chittyconnect bindings` → dispatch concierge to inspect deployed bindings, restore any missing via safe-deploy, audit post-deploy. -- `/chico rotate CF token #215` → dispatch concierge to handle CF API token rotation (chittyconnect#215), through ChittySecrets + gh secret set, no operator credential asking. +- `/chico rotate CF token #215` → dispatch concierge to handle CF API token rotation (chittyconnect#215), through the ChittyConnect broker lane + gh secret set, no operator credential asking. - `/chico claim Action 1b 2aacb316` → dispatch concierge to claim the chittyagent-tasks task `2aacb316` (ChittyConnect neon_auth readiness PR) via `tasks_claim`, execute, then `tasks_complete`. - `/chico audit deployed bindings` → dispatch concierge for a one-shot drift audit across the chittyconnect / chittyagent-viewport / chittyagent-* workers using their safe-deploy scripts. ## Where the concierge lives -- Plugin id: `chittyos-core:chittyconnect-concierge` -- Lane: credentials, connections, secrets, ChittySecrets, wrangler secrets, CF tokens, KV/D1 bindings, deploy hygiene. +- Plugin id: `chittyos-core:chittyagent-connect` +- Lane: credentials, connections, secrets, ChittyConnect/ChittySecrets brokering, wrangler secrets, CF tokens, KV/D1 bindings, deploy hygiene. - Memory alias: "chico-keys" (saved in [[orchestrate-via-systems]]). diff --git a/canonical/skills/chitty-autonomy-affirm.md b/canonical/skills/chitty-autonomy-affirm.md index 2571bbe..7b8f477 100644 --- a/canonical/skills/chitty-autonomy-affirm.md +++ b/canonical/skills/chitty-autonomy-affirm.md @@ -8,6 +8,7 @@ plugin: chittyagent-autobot runtimes: - claude-code - codex + - gemini classification: - governance - autonomy diff --git a/canonical/skills/chitty-autonomy-cicd.md b/canonical/skills/chitty-autonomy-cicd.md index 5ac95fa..c12a2bf 100644 --- a/canonical/skills/chitty-autonomy-cicd.md +++ b/canonical/skills/chitty-autonomy-cicd.md @@ -8,6 +8,7 @@ plugin: chittyagent-autobot runtimes: - claude-code - codex + - gemini classification: - governance - autonomy diff --git a/canonical/skills/chitty-autonomy-discover.md b/canonical/skills/chitty-autonomy-discover.md index b314ec6..0ea1eed 100644 --- a/canonical/skills/chitty-autonomy-discover.md +++ b/canonical/skills/chitty-autonomy-discover.md @@ -8,6 +8,7 @@ plugin: chittyagent-autobot runtimes: - claude-code - codex + - gemini classification: - governance - autonomy diff --git a/canonical/skills/chitty-autonomy-generate.md b/canonical/skills/chitty-autonomy-generate.md index fbf654d..02f5071 100644 --- a/canonical/skills/chitty-autonomy-generate.md +++ b/canonical/skills/chitty-autonomy-generate.md @@ -8,6 +8,7 @@ plugin: chittyagent-autobot runtimes: - claude-code - codex + - gemini classification: - governance - autonomy diff --git a/canonical/skills/chitty-autonomy-implement.md b/canonical/skills/chitty-autonomy-implement.md index f797fa6..722513e 100644 --- a/canonical/skills/chitty-autonomy-implement.md +++ b/canonical/skills/chitty-autonomy-implement.md @@ -8,6 +8,7 @@ plugin: chittyagent-autobot runtimes: - claude-code - codex + - gemini classification: - governance - autonomy diff --git a/canonical/skills/chitty-autonomy-plan.md b/canonical/skills/chitty-autonomy-plan.md index f5765aa..395784b 100644 --- a/canonical/skills/chitty-autonomy-plan.md +++ b/canonical/skills/chitty-autonomy-plan.md @@ -8,6 +8,7 @@ plugin: chittyagent-autobot runtimes: - claude-code - codex + - gemini classification: - governance - autonomy diff --git a/canonical/skills/chitty-autonomy-ship.md b/canonical/skills/chitty-autonomy-ship.md index 7b76e81..38e53f2 100644 --- a/canonical/skills/chitty-autonomy-ship.md +++ b/canonical/skills/chitty-autonomy-ship.md @@ -8,6 +8,7 @@ plugin: chittyagent-autobot runtimes: - claude-code - codex + - gemini classification: - governance - autonomy diff --git a/canonical/skills/chitty-autonomy-tidy.md b/canonical/skills/chitty-autonomy-tidy.md index de6bb4b..35b8f0a 100644 --- a/canonical/skills/chitty-autonomy-tidy.md +++ b/canonical/skills/chitty-autonomy-tidy.md @@ -8,6 +8,7 @@ plugin: chittyagent-autobot runtimes: - claude-code - codex + - gemini classification: - governance - autonomy diff --git a/canonical/skills/chitty-autonomy.md b/canonical/skills/chitty-autonomy.md index 2153118..7b6feb1 100644 --- a/canonical/skills/chitty-autonomy.md +++ b/canonical/skills/chitty-autonomy.md @@ -10,6 +10,7 @@ plugin: chittyagent-autobot runtimes: - claude-code - codex + - gemini classification: - governance - autonomy diff --git a/canonical/skills/chitty-cleanup.md b/canonical/skills/chitty-cleanup.md index 44bb4af..fcedb0e 100644 --- a/canonical/skills/chitty-cleanup.md +++ b/canonical/skills/chitty-cleanup.md @@ -7,6 +7,7 @@ plugin: chittyos-core runtimes: - claude-code - codex + - gemini classification: - session - operations diff --git a/canonical/skills/chitty-deploy.md b/canonical/skills/chitty-deploy.md index bdba52f..474f407 100644 --- a/canonical/skills/chitty-deploy.md +++ b/canonical/skills/chitty-deploy.md @@ -7,6 +7,7 @@ plugin: chittyos-devops runtimes: - claude-code - codex + - gemini classification: - operations - deployment diff --git a/canonical/skills/chitty-health.md b/canonical/skills/chitty-health.md index d643cf3..a918c41 100644 --- a/canonical/skills/chitty-health.md +++ b/canonical/skills/chitty-health.md @@ -7,6 +7,7 @@ plugin: chittyos-devops runtimes: - claude-code - codex + - gemini classification: - operations - deployment diff --git a/canonical/skills/chitty-pipelines.md b/canonical/skills/chitty-pipelines.md index 5a11887..c5a780b 100644 --- a/canonical/skills/chitty-pipelines.md +++ b/canonical/skills/chitty-pipelines.md @@ -7,6 +7,7 @@ plugin: chittyos-devops runtimes: - claude-code - codex + - gemini classification: - operations - deployment diff --git a/canonical/skills/chitty-registry.md b/canonical/skills/chitty-registry.md index f2be51e..88e9a3d 100644 --- a/canonical/skills/chitty-registry.md +++ b/canonical/skills/chitty-registry.md @@ -7,6 +7,7 @@ plugin: chittyos-devops runtimes: - claude-code - codex + - gemini classification: - operations - deployment diff --git a/canonical/skills/chittycontext.md b/canonical/skills/chittycontext.md index e2f22c9..52a57b8 100644 --- a/canonical/skills/chittycontext.md +++ b/canonical/skills/chittycontext.md @@ -7,6 +7,7 @@ plugin: chittyos-core runtimes: - claude-code - codex + - gemini classification: - session - operations diff --git a/canonical/skills/chittygws.md b/canonical/skills/chittygws.md index 7648ef6..0aba1b0 100644 --- a/canonical/skills/chittygws.md +++ b/canonical/skills/chittygws.md @@ -7,6 +7,7 @@ plugin: chittyos-mcp runtimes: - claude-code - codex + - gemini classification: - integration - authentication diff --git a/canonical/skills/chittyos-compliance.md b/canonical/skills/chittyos-compliance.md index 0df9757..2674214 100644 --- a/canonical/skills/chittyos-compliance.md +++ b/canonical/skills/chittyos-compliance.md @@ -7,6 +7,7 @@ plugin: chittyos-devops runtimes: - claude-code - codex + - gemini classification: - operations - deployment diff --git a/canonical/skills/chittyos-security-review.md b/canonical/skills/chittyos-security-review.md new file mode 100644 index 0000000..0a53a4f --- /dev/null +++ b/canonical/skills/chittyos-security-review.md @@ -0,0 +1,63 @@ +--- +name: chittyos-security-review +canon_uri: chittycanon://core/services/chittymarket#skills/chittyos-security-review +description: | + Review ChittyOS code and configuration for security weaknesses across Cloudflare Workers, + Workers AI, MCP/Ch1tty boundaries, ChittyConnect and ChittySecrets, D1/Neon/R2, webhooks, + and Workers Builds. Triggers on security review, hardening, secret handling, auth boundary, + Worker security, MCP security, or threat-preflight requests. +kind: skill +plugin: chittyos-security +runtimes: + - claude-code + - codex + - gemini +classification: + - security + - governance + - operations +--- + +# ChittyOS Security Review + +Perform a read-only, evidence-based review before proposing changes. Inspect the real repository, +its `CHARTER.md`, `CHITTY.md`, `CLAUDE.md`, `AGENTS.md`, Worker configuration, routes, bindings, +workflows, and tests. Do not request or expose credentials. + +## Review order + +1. Establish scope: repository, Worker/service, changed files, data handled, and deployment path. +2. Discover existing owners and canonical services before suggesting a new control. Reuse ChittyConnect, + ChittyAuth, ChittyID, ChittySecrets, ChittyCanon, ChittyTrack, and Ch1tty where applicable. +3. Trace trust boundaries: browser/client → Worker → MCP/Ch1tty → upstream service → D1/Neon/R2/KV. +4. Inspect authentication, authorization, tenant isolation, input validation, output handling, CORS, + webhook verification, replay protection, rate limits, and failure behavior. +5. Inspect `wrangler.toml`/`wrangler.jsonc`, bindings, routes, compatibility date, observability, + Workers Builds triggers, and GitHub workflows for secret leakage or fail-open deployment gates. +6. Check AI-specific risks: prompt injection, untrusted tool arguments, model-output trust, data leakage, + unbounded prompts/completions, provider fallback, usage limits, and generation persistence. +7. Classify each finding as critical, high, medium, low, or informational, with file/line evidence. + +## ChittyOS rules + +- Secrets and tokens are broker-managed. Never grep, print, paste, rotate, or invent secret values. +- Route credential and deployment intent through ChittyConnect/Chico; fail closed when the broker is unavailable. +- Treat Ch1tty as the MCP umbrella and do not bypass it for orchestration or intent-driven calls. +- Never treat KV as the authoritative store for security state, idempotency, audit, or custody records. +- Prefer Workers Builds for deployment. GitHub Actions may validate but must not become a deployment queue. +- Do not add paid-GitHub assumptions, broad workflow fan-out, or duplicate deploy workflows. +- Do not weaken auth, CORS, tenant boundaries, logging redaction, or deploy gates to make a test pass. +- Findings must distinguish a confirmed vulnerability from a missing control or an unverified assumption. + +## Output + +Return: + +1. Scope and evidence inspected. +2. Findings table: severity, evidence, impact, exploit/precondition, and recommended remediation. +3. Positive controls already present. +4. Prioritized remediation backlog with smallest safe next steps. +5. Tests or probes that would prove each fix. +6. Explicit caveats where runtime, registry, binding, or provider state was unavailable. + +Do not implement fixes, mutate infrastructure, or change credentials unless separately requested and approved. diff --git a/canonical/skills/chittyos-threat-model.md b/canonical/skills/chittyos-threat-model.md new file mode 100644 index 0000000..43b66d7 --- /dev/null +++ b/canonical/skills/chittyos-threat-model.md @@ -0,0 +1,63 @@ +--- +name: chittyos-threat-model +canon_uri: chittycanon://core/services/chittymarket#skills/chittyos-threat-model +description: | + Build a practical threat model for ChittyOS services and workflows, including Cloudflare Workers, + AI inference, MCP tools, webhooks, D1/Neon/R2 data flows, service ownership, and Workers Builds. + Triggers on threat model, abuse cases, attack surface, security architecture, or ownership map requests. +kind: skill +plugin: chittyos-security +runtimes: + - claude-code + - codex + - gemini +classification: + - security + - architecture + - governance +--- + +# ChittyOS Threat Model + +Create a bounded threat model from repository evidence. This is a design and review artifact, not an +authorization to deploy, change permissions, or modify production data. + +## Method + +1. Define the system, intended users, protected assets, security objectives, and explicit out-of-scope areas. +2. Map components and trust boundaries using actual routes, bindings, MCP tools, queues, databases, buckets, + AI providers, and build/deploy triggers. +3. Build an ownership map: service/repository, canonical owner, data owner, deploy authority, secret broker, + downstream consumers, and evidence source. Mark unknown ownership as a finding. +4. Enumerate abuse cases for spoofing, tampering, repudiation, information disclosure, denial of service, + and privilege escalation. Include AI prompt/tool abuse and webhook replay where relevant. +5. Rank risks by likelihood, impact, exploitability, and blast radius. Separate design risk from confirmed exposure. +6. Identify preventive, detective, and recovery controls. Prefer existing ChittyOS primitives over new infrastructure. +7. Produce a minimal remediation sequence and verification plan. + +## Required checks + +- Authn and authz are enforced at every externally reachable route and tool boundary. +- Tenant/user scope is carried through reads, writes, background jobs, and result retrieval. +- Webhooks authenticate payloads, reject stale/replayed events, and handle duplicate delivery safely. +- AI tools constrain arguments, validate model output before side effects, and cap input/output/resource usage. +- Prompts, outputs, tokens, headers, and secret material are not written to logs or public storage. +- D1/Neon/R2 permissions follow least privilege and large/sensitive objects have retention controls. +- Worker restarts, client disconnects, retries, and provider failures do not create fail-open state. +- Workers Builds and GitHub checks cannot silently bypass required validation or deploy authorization. +- Ownership, escalation path, and evidence links are recorded for every high-risk asset. + +## Output + +Return: + +- system and trust-boundary summary; +- asset/owner/data-flow table; +- prioritized STRIDE-style abuse-case table; +- existing controls and control gaps; +- remediation backlog with owner, dependency, and verification test; +- residual risk and assumptions; +- explicit human-review items for deploy, credential custody, destructive actions, or external communication. + +Never claim a service is secure merely because tests pass. A threat model is complete only when unknown +boundaries and ownership are called out, not silently assumed away. diff --git a/canonical/skills/chittyxl.md b/canonical/skills/chittyxl.md index 8ffecbc..be44152 100644 --- a/canonical/skills/chittyxl.md +++ b/canonical/skills/chittyxl.md @@ -7,6 +7,7 @@ plugin: chittyos-core runtimes: - claude-code - codex + - gemini classification: - session - operations diff --git a/canonical/skills/cli-surface-projection.md b/canonical/skills/cli-surface-projection.md index 1ab5e0b..9d92e20 100644 --- a/canonical/skills/cli-surface-projection.md +++ b/canonical/skills/cli-surface-projection.md @@ -8,6 +8,7 @@ plugin: nowebmaster runtimes: - claude-code - codex + - gemini classification: - cli - runbook diff --git a/canonical/skills/cross-surface-hotloading.md b/canonical/skills/cross-surface-hotloading.md index d824cb4..390bef4 100644 --- a/canonical/skills/cross-surface-hotloading.md +++ b/canonical/skills/cross-surface-hotloading.md @@ -8,6 +8,7 @@ plugin: nowebmaster runtimes: - claude-code - codex + - gemini classification: - deployment - provider-projection diff --git a/canonical/skills/dispute.md b/canonical/skills/dispute.md index 958b311..6745ccd 100644 --- a/canonical/skills/dispute.md +++ b/canonical/skills/dispute.md @@ -12,6 +12,7 @@ plugin: chittyos-legal runtimes: - claude-code - codex + - gemini classification: - legal - evidence diff --git a/canonical/skills/docket.md b/canonical/skills/docket.md index f9347be..eb03e39 100644 --- a/canonical/skills/docket.md +++ b/canonical/skills/docket.md @@ -7,6 +7,7 @@ plugin: chittyos-legal runtimes: - claude-code - codex + - gemini classification: - legal - evidence diff --git a/canonical/skills/evidence-collect.md b/canonical/skills/evidence-collect.md index bba0c74..a0fa0ee 100644 --- a/canonical/skills/evidence-collect.md +++ b/canonical/skills/evidence-collect.md @@ -7,6 +7,7 @@ plugin: chittyos-legal runtimes: - claude-code - codex + - gemini classification: - legal - evidence diff --git a/canonical/skills/evidence-egress.md b/canonical/skills/evidence-egress.md index dc45e1f..590cc53 100644 --- a/canonical/skills/evidence-egress.md +++ b/canonical/skills/evidence-egress.md @@ -7,6 +7,7 @@ plugin: chittyos-legal runtimes: - claude-code - codex + - gemini classification: - legal - evidence diff --git a/canonical/skills/fact-governance.md b/canonical/skills/fact-governance.md index cd49044..345de4e 100644 --- a/canonical/skills/fact-governance.md +++ b/canonical/skills/fact-governance.md @@ -7,6 +7,7 @@ plugin: chittyos-legal runtimes: - claude-code - codex + - gemini classification: - legal - evidence diff --git a/canonical/skills/goal-creator.md b/canonical/skills/goal-creator.md index 9d338d2..f590edb 100644 --- a/canonical/skills/goal-creator.md +++ b/canonical/skills/goal-creator.md @@ -10,6 +10,7 @@ classification: runtimes: - claude-code - codex + - gemini plugin: chittyos-core aliases: diff --git a/canonical/skills/hygiene.md b/canonical/skills/hygiene.md index b461760..bf9c1be 100644 --- a/canonical/skills/hygiene.md +++ b/canonical/skills/hygiene.md @@ -10,6 +10,7 @@ classification: runtimes: - claude-code - codex + - gemini plugin: chittyos-core --- diff --git a/canonical/skills/market.md b/canonical/skills/market.md index 5d00a7f..54a61ea 100644 --- a/canonical/skills/market.md +++ b/canonical/skills/market.md @@ -7,6 +7,7 @@ plugin: chittymarket-manager runtimes: - claude-code - codex + - gemini classification: - marketplace - discovery diff --git a/canonical/skills/mcp-tool-calling-rules.md b/canonical/skills/mcp-tool-calling-rules.md index 35fa2fc..fd522fb 100644 --- a/canonical/skills/mcp-tool-calling-rules.md +++ b/canonical/skills/mcp-tool-calling-rules.md @@ -8,6 +8,7 @@ plugin: nowebmaster runtimes: - claude-code - codex + - gemini classification: - mcp - tool-invocation diff --git a/canonical/skills/nb-development-defaults.md b/canonical/skills/nb-development-defaults.md index 1e03400..bdaebfe 100644 --- a/canonical/skills/nb-development-defaults.md +++ b/canonical/skills/nb-development-defaults.md @@ -11,6 +11,7 @@ classification: runtimes: - claude-code - codex + - gemini plugin: chittyos-core --- @@ -419,17 +420,40 @@ Every dispatched subagent should default to `ch1tty/cast` for orchestration and ## Workers Builds (CF CI/CD) -All ChittyOS workers deploy via Cloudflare Workers Builds (git-triggered). Config is managed via API, not dashboard. +Cloudflare Workers Builds is the normal build and deployment path for ChittyOS workers. +GitHub remains the source-control and review surface; it is not a second deployment +system. Configure Workers Builds through the API, not the dashboard. - **API base**: `https://api.cloudflare.com/client/v4/accounts/{ACCOUNT_ID}/builds/` - **Auth**: `Authorization: Bearer {cfut_ account token}` — needs "Workers Builds Configuration:Edit" permission - **Script ID**: Use script TAG (not name). Get via `GET /workers/services/{name}` → `.result.default_environment.script_tag` - **Triggers**: Each worker has 2 (production branch + non-production). PATCH to update, POST to create. - **Key endpoints**: `/builds/triggers` (CRUD), `/builds/workers/{script_tag}/triggers` (list), `/builds/triggers/{uuid}/builds` (manual trigger) -- **Pattern**: Workers with `env.production` blocks deploy via `npx wrangler deploy --env production` +- **Normal path**: a push to the configured branch triggers the Cloudflare Workers Build + and deployment. +- **Wrangler**: use `npx wrangler deploy --env production` for local development, + `--dry-run` validation, or an explicitly approved emergency/manual deployment only. + Do not run Wrangler deployment in parallel with the Workers Build for the same commit. - **Shared deps**: Workers importing from `../shared/` use build command `cd ../shared && npm ci` - **Watch paths**: Shared importers watch both `/workers/{name}/*` and `/workers/shared/*` +### GitHub free-tier operating model + +Keep GitHub Actions lightweight and non-duplicative. Repository workflows should do +only inexpensive validation such as lint, typecheck, unit tests, and configuration +checks. Full builds and deployments belong to Cloudflare Workers Builds unless a +repository has an explicitly documented exception. + +- Do not duplicate a Cloudflare deployment in GitHub Actions. +- Do not assume paid GitHub features, unlimited minutes, required reviewers, or + auto-merge are available. +- Prefer one small repository workflow template over large, frequently changing + workflow copies. +- Treat the Cloudflare build result as the deployment gate and record the build URL + or ID in the release/incident note when operational evidence is needed. +- Use path filters and branch filters so unrelated repository changes do not trigger + Worker builds. + ## Review and Audit Bias - For review requests, findings come first. diff --git a/canonical/skills/nowebmaster-architecture.md b/canonical/skills/nowebmaster-architecture.md index b3d23e9..16dcc97 100644 --- a/canonical/skills/nowebmaster-architecture.md +++ b/canonical/skills/nowebmaster-architecture.md @@ -8,6 +8,7 @@ plugin: nowebmaster runtimes: - claude-code - codex + - gemini classification: - architecture - capability-lifecycle diff --git a/canonical/skills/retrospect.md b/canonical/skills/retrospect.md index 4dac129..2237284 100644 --- a/canonical/skills/retrospect.md +++ b/canonical/skills/retrospect.md @@ -7,6 +7,7 @@ plugin: chittyos-core runtimes: - claude-code - codex + - gemini classification: - learning - governance diff --git a/canonical/skills/skill-creator.md b/canonical/skills/skill-creator.md index 9467136..e882da3 100644 --- a/canonical/skills/skill-creator.md +++ b/canonical/skills/skill-creator.md @@ -11,6 +11,7 @@ classification: runtimes: - claude-code - codex + - gemini plugin: chittyos-core overrides: claude-plugins-official:skill-creator diff --git a/canonical/skills/wrangler-audit.md b/canonical/skills/wrangler-audit.md index 25e0d76..f0c0ef1 100644 --- a/canonical/skills/wrangler-audit.md +++ b/canonical/skills/wrangler-audit.md @@ -7,6 +7,7 @@ plugin: chittyos-devops runtimes: - claude-code - codex + - gemini classification: - operations - deployment diff --git a/plugins/chittyagent-autobot/gemini-skills/chitty-autonomy-affirm/SKILL.md b/plugins/chittyagent-autobot/gemini-skills/chitty-autonomy-affirm/SKILL.md new file mode 100644 index 0000000..451e0d0 --- /dev/null +++ b/plugins/chittyagent-autobot/gemini-skills/chitty-autonomy-affirm/SKILL.md @@ -0,0 +1,142 @@ +--- +name: chitty-autonomy-affirm +description: Phase 0 — Sovereignty Affirmation. Requests a HMAC-SHA256-signed certificate from ChittyCert (cert.chitty.cc) attesting the synthetic entity's identity, status, and scope of agency for the upcoming autonomy run. Persists the cert payload as SOVEREIGNTY.cert and emits a ChittyChronicle entry. The agent does NOT proceed without a valid cert. +canonical_uri: chittycanon://skills/chitty-autonomy-affirm +status: DRAFT +--- + +# Phase 0: Sovereignty Affirmation + +## Purpose + +Synthetic entities (Claude contexts) operating under ChittyOS canonical governance are P-Synthetic Persons with agency. Per `chittycanon://gov/governance#sovereignty`, sovereignty is **earned, not granted** — but for any given run of autonomous work, the entity must affirm its identity, current sovereignty status, and the scope of authority it claims for the work, and that affirmation must be CERTIFIED by the ChittyOS Certificate Authority (ChittyCert). + +This phase: +1. Identifies the synthetic entity (ChittyID, P-type, status). +2. Requests a Sovereignty Affirmation cert from ChittyCert. +3. Persists the signed cert response. +4. Emits a ChittyChronicle audit entry anchoring the run. + +## Inputs + +| Field | Source | Notes | +|---|---|---| +| `chitty_id` | `chittycontext/session_binding.json` or `can chitty whoami` | The P-Synthetic ChittyID currently bound to this session | +| `feature` | parent skill argument | Kebab-case feature name | +| `branch` | derived from feature | `feat/` by default | +| `repo` | working directory | `` from git remote | +| `valid_until` | now + 24h (default) | ISO 8601; clamp to ≤72h max | + +## Process + +### 1. Resolve identity + +```bash +chitty_id=$(can chitty whoami --field chitty_id 2>/dev/null \ + || jq -r .chitty_id ~/.claude/chittycontext/session_binding.json) +``` + +If `chitty_id` is missing, fail with: "No bound ChittyID — cannot affirm sovereignty. Run `can chitty authenticate-context` first." + +### 2. Request cert from ChittyCert + +Do not resolve or inject the ChittyCert token yourself. Dispatch the request through the +ChittyConnect broker (`/chico`), which holds the binding and performs the authenticated call. +If the broker is unavailable, fail closed with `POLICY_BLOCKED_CHITTYCONNECT_UNAVAILABLE` — +never fall back to a local credential read. + +Brief the broker with this request (it supplies `Authorization` itself): + +```bash +# POST https://mychitty.com/api/v1/identity/api/v1/issue +# Content-Type: application/json +jq -nc \ + --arg cid "$chitty_id" \ + --arg ft "$feature" \ + --arg br "$branch" \ + --arg rp "$repo" \ + --arg vu "$valid_until" \ + '{ + type: "TRUST_CHAIN", + subject_chitty_id: $cid, + subject_type: "P", + subject_status: "Operational", + purpose: "synthetic-entity-sovereignty-affirmation", + scope: { feature: $ft, branch: $br, repo: $rp, valid_until: $vu }, + constraints: [ + "Cannot bypass canonical pipelines (POST /collect, /documents, /vault/ingest)", + "Must cite chittycanon:// URIs for entity types (P/L/T/E/A — all five)", + "Must consult ChittyRegistry before scaffolding new services", + "Must require Pentad (CHARTER, CHITTY, CLAUDE, SECURITY, AGENTS) for new services", + "Must emit ChittyChronicle audit entry per phase boundary" + ], + ledger_anchor: "chittycanon://core/services/chittychronicle" + }' +``` + +The response (cert envelope with `cert_id`, `signature`, `issued_at`, `expires_at`, full subject + scope) is persisted: + +```bash +mkdir -p chittycontext/structured-autonomy/${feature} +echo "$response" > chittycontext/structured-autonomy/${feature}/SOVEREIGNTY.cert +chmod 600 chittycontext/structured-autonomy/${feature}/SOVEREIGNTY.cert +``` + +### 3. Emit ChittyChronicle entry + +```bash +curl -sS -X POST https://chronicle.chitty.cc/api/v1/entries \ + -H "Authorization: Bearer $CT_TOKEN" \ + -d "$(jq -nc \ + --arg cid "$chitty_id" \ + --arg ft "$feature" \ + --arg crt "$(jq -r .cert_id < chittycontext/structured-autonomy/${feature}/SOVEREIGNTY.cert)" \ + "{ + uri: (\"chittycanon://docs/audit/\" + \$ft + \"/affirm\"), + type: \"phase_boundary\", + phase: \"affirm\", + actor_chitty_id: \$cid, + cert_id: \$crt, + payload: { feature: \$ft, phase: \"affirm\", outcome: \"completed\" } + }")" +``` + +### 4. Update state + +```bash +state=chittycontext/structured-autonomy/${feature}/state.json +jq ".phase = \"affirm\" | .cert_id = \"$(jq -r .cert_id < SOVEREIGNTY.cert)\" | .phase_history += [{phase: \"affirm\", completed_at: \"$(date -u +%FT%TZ)\"}]" \ + $state > $state.tmp && mv $state.tmp $state +``` + +## Failure Modes + +| Failure | Action | +|---|---| +| ChittyCert returns 401 | Token misconfigured. Stop. Surface to user. | +| ChittyCert returns 403 (entity not authorized) | Synthetic entity does not have permission to affirm. Stop. | +| ChittyCert returns 5xx | Retry once with exponential backoff. Then stop. | +| Cert payload missing required fields | Treat as invalid; do not persist. Stop. | +| Cert `expires_at < now + 30min` | Re-request with longer `valid_until`. | +| ChittyChronicle write fails | Persist cert anyway, mark state as `affirm_pending_chronicle`. Retry chronicle write at next phase boundary. | + +## Output Contract + +Returns a JSON object to the parent orchestrator: +```json +{ + "phase": "affirm", + "status": "completed", + "cert_id": "", + "cert_path": "chittycontext/structured-autonomy//SOVEREIGNTY.cert", + "expires_at": "", + "chronicle_entry": "" +} +``` + +## See Also + +- `chittycanon://gov/governance#sovereignty` — sovereignty lifecycle definition +- `chittycanon://core/services/chitty-cert` — cert issuance contract +- `chittycanon://core/services/chittychronicle` — audit ledger +- `chittycanon://docs/sovereignty-affirmation-v1` — this affirmation pattern (proposed) diff --git a/plugins/chittyagent-autobot/gemini-skills/chitty-autonomy-cicd/SKILL.md b/plugins/chittyagent-autobot/gemini-skills/chitty-autonomy-cicd/SKILL.md new file mode 100644 index 0000000..c0965b1 --- /dev/null +++ b/plugins/chittyagent-autobot/gemini-skills/chitty-autonomy-cicd/SKILL.md @@ -0,0 +1,49 @@ +--- +name: chitty-autonomy-cicd +description: Phase 8 — CI/CD scaffolding. Creates .github/workflows/ for the canonical ChittyOS deploy pipeline. Audits CLOUDFLARE_API_TOKEN GitHub-Actions secret scopes against project needs (Workers Scripts:Edit always; Workers Secrets Store:Edit if secrets_store bindings; Workers Pipelines:Edit if pipelines; Workers R2 Data Catalog:Edit if Iceberg sinks). Catches the deploy-loop class of failure up-front. +canonical_uri: chittycanon://skills/chitty-autonomy-cicd +status: DRAFT +--- + +# Phase 8: CI/CD + +## Why this phase exists + +Observed failure (2026-05-01): chittyconnect Worker entered a deploy loop because the GitHub Actions `CLOUDFLARE_API_TOKEN` secret lacked `Workers Secrets Store:Edit` scope. Every PR merge → CI → deploy fails with code 10021 → no rollback → next merge tries again. **Phase 8 catches token-scope gaps up-front so this class of failure cannot recur.** + +## Process + +1. Verify cert valid. +2. Detect build/deploy mode: + - Cloudflare Worker → `wrangler deploy` + - npm package → `npm publish` + - Static site → CF Pages + - Mixed → branch the workflow file accordingly. +3. Scaffold `.github/workflows/`: + - `deploy.yml` — push to main → lint+test+deploy + - `pr-checks.yml` — on PR → lint+test + - `chitty-canon-check.yml` — invokes chittyagent-canon +4. **Token scope audit** — programmatically list scopes on `CLOUDFLARE_API_TOKEN`: + - REQUIRE: `Workers Scripts:Edit` (always) + - IF wrangler config has `secrets_store_secrets` → REQUIRE: `Workers Secrets Store:Edit` + - IF wrangler config has `pipelines` bindings → REQUIRE: `Workers Pipelines:Edit` + - IF wrangler config uses Iceberg / R2 Data Catalog sinks → REQUIRE: `Workers R2 Data Catalog:Edit` +5. If any required scope is missing, surface a precise checklist for the user to add via the dashboard. CF API doesn'\''t expose scope mutation; this is informational + dashboard-side. +6. Emit ChittyChronicle entry. + +## Output Contract + +```json +{ + "phase": "cicd", + "status": "completed", + "workflows_scaffolded": ["deploy.yml", "pr-checks.yml"], + "token_scopes_audit": { + "current": [...], + "required": [...], + "missing": [...] + }, + "user_action_required": false, + "chronicle_entry": "" +} +``` diff --git a/plugins/chittyagent-autobot/gemini-skills/chitty-autonomy-discover/SKILL.md b/plugins/chittyagent-autobot/gemini-skills/chitty-autonomy-discover/SKILL.md new file mode 100644 index 0000000..5806ccf --- /dev/null +++ b/plugins/chittyagent-autobot/gemini-skills/chitty-autonomy-discover/SKILL.md @@ -0,0 +1,142 @@ +--- +name: chitty-autonomy-discover +description: Phase 1 — MANDATORY ChittyOS Ecosystem Discovery. Queries ChittyRegistry for relevant services; reads the Pentad (CHARTER/CHITTY/CLAUDE/SECURITY/AGENTS) of any service the work will touch; checks ChittyCanon for canonical patterns; consults Ch1tty MCP for ecosystem state. Output is a `discovery.md` that the planner phase consumes. Closes the gap that led services to silently bypass canonical pipelines (e.g. building rclone-based ingestion instead of POSTing to /documents). +canonical_uri: chittycanon://skills/chitty-autonomy-discover +status: DRAFT +--- + +# Phase 1: Ecosystem Discovery + +## Why this phase exists + +Without forced discovery, agents build in a vacuum. Real-world failure mode (observed): an agent built a Drive→R2→/collect ingestion path because the user said "drop folder watcher", never consulting `POST /documents` (the canonical gatekeeper with dedup). The hookify rule `block-bypass-pipeline` would have flagged this in interactive Claude Code sessions, but the systemd-timer-driven runtime evaded it. The proper fix is a PRODUCT-level discovery gate, not a local hook. + +This phase is **MANDATORY**. The parent orchestrator refuses to advance to Plan without it. + +## Process + +### 1. Verify Sovereignty cert is valid + +```bash +cert_id=$(jq -r .cert_id < chittycontext/structured-autonomy/${feature}/SOVEREIGNTY.cert) +``` + +Dispatch the verify call through the ChittyConnect broker (`/chico`) — it holds the ChittyCert +binding and supplies `Authorization` itself. Never resolve or inject the token locally. If the +broker is unavailable, fail closed with `POLICY_BLOCKED_CHITTYCONNECT_UNAVAILABLE`. + +``` +POST https://mychitty.com/api/v1/identity/api/v1/verify +{"cert_id": ""} +``` + +The cert is valid when the response has `.valid == true`. + +If invalid, return to Phase 0 (re-affirm). + +### 2. Query ChittyRegistry + +```bash +curl -s https://registry.chitty.cc/api/services | jq '.[] | {name,tier,domain,status,canonicalUri}' \ + > chittycontext/structured-autonomy/${feature}/registry-snapshot.json +``` + +Then narrow to services likely relevant to the feature request: + +```bash +# AI assist — pass feature description + registry snapshot to a sub-prompt to +# identify candidate upstream/downstream services. Output a relevance ranking. +``` + +### 3. Read the Pentad of each relevant service + +For each candidate service S: + +```bash +for doc in CHARTER.md CHITTY.md CLAUDE.md SECURITY.md AGENTS.md; do + if [ -f ~/projects/github.com/CHITTY{FOUNDATION,OS,APPS}/$S/$doc ]; then + cat ~/projects/github.com/CHITTY{FOUNDATION,OS,APPS}/$S/$doc + else + # Pentad incomplete — record the gap; do not block discovery itself + echo "MISSING: $S/$doc" >> chittycontext/structured-autonomy/${feature}/pentad-gaps.txt + fi +done +``` + +Pentad gaps in EXISTING services are recorded but do not block; pentad gaps in NEW services scaffolded by THIS workflow DO block at Phase 9 (Ship). + +### 4. Consult Ch1tty MCP + +If `ch1tty` MCP server is connected: + +``` +mcp_tool: ch1tty.ecosystem_awareness +args: { feature: "", relevant_services: [...] } +``` + +Records current production state, recent incidents, blocking dependencies. + +### 5. Consult ChittyCanon for ontology + +```bash +# Local cache +cat ~/.claude/chittycontext/canon/ontology.json | jq '.entity_types' + +# Authoritative +curl -s https://canon.chitty.cc/api/v1/governance | jq '.entity_types' +``` + +If the work touches entity types (any of P/L/T/E/A), the planner will be required to cite `// @canon: chittycanon://gov/governance#core-types` in generated code. + +### 6. Generate discovery.md + +Single source-of-truth output for the planner phase: + +```markdown +# Discovery — + +**Cert:** (valid until ) + +## Relevant services +| Service | Tier | Domain | Role | Pentad complete? | +|---|---|---|---|---| + +## Canonical patterns to follow +- Pipeline: … (the relevant `chittycanon://core/services/X` and its endpoints) +- Auth: … +- Storage: … +- Audit: … + +## Identified canonical pipelines (DO NOT BYPASS) +- `POST /documents` (gatekeeper) — content + metadata, dedup +- `POST /collect` (registration only — file already in R2) +- `POST /vault/ingest` (batch from local vaults) +- `POST chitty-cert/api/v1/issue` (cert issuance) +- `POST chittychronicle/api/v1/entries` (audit) + +## Pentad gaps in existing services (informational) +- … + +## Discovered constraints +- … +``` + +## Failure Modes + +- ChittyRegistry unreachable → use `~/.claude/chittycontext/canon/ontology.json` cache + most recent registry-snapshot in any feature dir; mark discovery as `degraded`. +- Pentad missing for ALL relevant services → ABORT; the work touches services that are not yet documented and the autonomy run cannot proceed safely. User must Pentad the upstream services first. + +## Output Contract + +```json +{ + "phase": "discover", + "status": "completed", + "discovery_doc": "chittycontext/structured-autonomy//discovery.md", + "relevant_services": ["chittyconnect", "chittyevidence", ...], + "canonical_pipelines": ["/documents", "/collect", ...], + "pentad_gaps_existing": [...], + "ontology_touched": ["P", "T"], + "chronicle_entry": "" +} +``` diff --git a/plugins/chittyagent-autobot/gemini-skills/chitty-autonomy-generate/SKILL.md b/plugins/chittyagent-autobot/gemini-skills/chitty-autonomy-generate/SKILL.md new file mode 100644 index 0000000..9895f26 --- /dev/null +++ b/plugins/chittyagent-autobot/gemini-skills/chitty-autonomy-generate/SKILL.md @@ -0,0 +1,81 @@ +--- +name: chitty-autonomy-generate +description: Phase 4 — Implementation Doc Generator. Replaces structured-autonomy-generate. Reads plan.md, produces implementation.md with copy-paste TDD-aware code. NO placeholders. NO Cursor-syntax. Generated code carries canon citations and product-level enforcement annotations. +canonical_uri: chittycanon://skills/chitty-autonomy-generate +status: DRAFT +--- + +# Phase 4: Generate Implementation Doc + +## Inputs +- `plan.md` (validated; zero NEEDS_CLARIFICATION) +- `discovery.md` (canonical patterns, pipelines, schemas) +- `--tdd` flag (optional) + +## Process + +1. Verify plan and cert valid. +2. Pull current canonical patterns from each cited Charter URI (live, not training). +3. For each commit in plan.md, generate: + - File path(s) per project conventions (read project's CLAUDE.md). + - **TDD path** (if `--tdd`): test file first (runnable, fails meaningfully), then implementation. + - **Non-TDD path**: implementation + verification commands. + - Required `// @canon: chittycanon://...` citations. + - Auth boilerplate per project's SECURITY.md. +4. Write `implementation.md` with markdown checkboxes per item. +5. Each commit ends with `STOP & COMMIT` (parent drives the pause). +6. Emit ChittyChronicle entry. + +## implementation.md template + +```markdown +# — Implementation + +**Cert:** +**Plan:** [plan.md](./plan.md) + +## Commit 1: + +### Test (TDD only) +- [ ] Create ``: +\`\`\` + +\`\`\` +- [ ] Run `` — confirm FAIL for expected reason. + +### Implementation +- [ ] Edit ``: +\`\`\` +// @canon: chittycanon://gov/governance#core-types (if entity types touched) + +\`\`\` +- [ ] Run `` — confirm PASS. +- [ ] Run ``, `` — clean. +- [ ] Commit: `: ` + +### Verification +- [ ] `` + +### STOP & COMMIT +``` + +## Constraints on generated code + +- NO `rclone copy` to evidence buckets — use canonical pipeline endpoint. +- NO direct `env.DOCUMENTS.put` outside `gatekeeper.ts` / `intake-worker.ts`. +- NO `wrangler deploy` raw — use CI workflow. +- NO `#tool:` / `#context7` Cursor syntax. +- Every entity-type validation MUST list all five (P/L/T/E/A). + +## Output Contract + +```json +{ + "phase": "generate", + "status": "completed", + "implementation_doc": "chittycontext/structured-autonomy//implementation.md", + "commits": [{"n": 1, "files": [...], "tdd": false}], + "canon_citations_required": [...], + "chronicle_entry": "" +} +``` diff --git a/plugins/chittyagent-autobot/gemini-skills/chitty-autonomy-implement/SKILL.md b/plugins/chittyagent-autobot/gemini-skills/chitty-autonomy-implement/SKILL.md new file mode 100644 index 0000000..02d0316 --- /dev/null +++ b/plugins/chittyagent-autobot/gemini-skills/chitty-autonomy-implement/SKILL.md @@ -0,0 +1,58 @@ +--- +name: chitty-autonomy-implement +description: Phase 5 — Implementation Executor. Replaces structured-autonomy-implement. Walks implementation.md commit-by-commit, runs tests, formats/lints inline, commits each step. Invokes superpowers:test-driven-development if --tdd was set; superpowers:systematic-debugging on test failure. Re-verifies sovereignty cert before destructive ops. +canonical_uri: chittycanon://skills/chitty-autonomy-implement +status: DRAFT +--- + +# Phase 5: Implement + +## Inputs +- `implementation.md` +- Sovereignty cert (re-verified at phase entry) + +## Process per commit + +1. Pre-commit cert check — `POST cert.chitty.cc/api/v1/verify`. If invalid, abort. +2. Apply all unchecked items in current commit. Use `Edit` tool with bytes-exact matches; refuse fuzzy edits. +3. Run verification commands. On failure: + - Invoke `superpowers:systematic-debugging`. + - Fix in-place; do NOT silently work around. + - On unfixable failure, return to Phase 4 with the symptom. +4. Run formatters/linters (prettier, eslint, language-appropriate). If still dirty after auto-fix, surface as review issue but commit. +5. Stage exactly the files listed in the plan; refuse `git add -A`. +6. Commit message: `(): [cert: ]`. +7. Mark all items checked in implementation.md. +8. Emit ChittyChronicle entry `chittycanon://docs/audit//commit-`. +9. Pause for parent orchestrator. + +## Constraints + +- No code outside what plan specifies. +- No `--no-verify` on git commit (skips hooks). +- No `git add -A`. +- If a product-level hook blocks the commit, surface the block as Phase 5 failure; loop back to Phase 4. + +## Output Contract per commit + +```json +{ + "phase": "implement", + "commit_n": 1, + "status": "committed", + "sha": "", + "files_changed": [...], + "tests_passed": true, + "lint_clean": true, + "chronicle_entry": "" +} +``` + +## Failure recovery + +| Symptom | Action | +|---|---| +| Test fails after fix attempts | `superpowers:systematic-debugging`; if still red, back to Phase 4 | +| Hook blocks commit | Read output; if canonical-pipeline-bypass, back to Phase 4 with corrective instruction | +| Cert expired mid-phase | Pause; request renewal via Phase 0; resume | +| Edit tool fails (old_string not unique) | Surface conflict; do not blind-edit | diff --git a/plugins/chittyagent-autobot/gemini-skills/chitty-autonomy-plan/SKILL.md b/plugins/chittyagent-autobot/gemini-skills/chitty-autonomy-plan/SKILL.md new file mode 100644 index 0000000..e9eafbd --- /dev/null +++ b/plugins/chittyagent-autobot/gemini-skills/chitty-autonomy-plan/SKILL.md @@ -0,0 +1,76 @@ +--- +name: chitty-autonomy-plan +description: Phase 3 — Plan Generation. Replaces structured-autonomy-plan with ChittyOS-canonical version. Reads discovery.md, breaks the feature into commits, generates a plan.md with [NEEDS_CLARIFICATION] markers that BLOCK the next phase until resolved. Cites canonical URIs for entity-type touches. No code, no Cursor-syntax, no Windows-API debt. +canonical_uri: chittycanon://skills/chitty-autonomy-plan +status: DRAFT +--- + +# Phase 3: Plan + +## Inputs +- `chittycontext/structured-autonomy//discovery.md` (mandatory) +- `chittycontext/structured-autonomy//SOVEREIGNTY.cert` (verified valid) +- Conversation context from Phase 2 (brainstorming output, if any) + +## Process + +1. Verify cert + discovery are present. If either missing, return to prior phase. +2. Determine commit count: SIMPLE features = 1 commit; COMPLEX = N (each independently testable). +3. Generate `plan.md` to `chittycontext/structured-autonomy//plan.md`. +4. Validate `[NEEDS_CLARIFICATION]` count. +5. If count > 0: PAUSE for user input. Re-enter Phase 3 after answers. +6. Emit ChittyChronicle entry `chittycanon://docs/audit//plan`. + +## plan.md template + +```markdown +# + +**Branch:** `feat/` +**Sovereignty cert:** (expires ) +**Discovery doc:** [discovery.md](./discovery.md) + +## Goal +<1-2 sentences> + +## Canonical alignment +- Touches entity types:

*(if any, code MUST cite `// @canon: chittycanon://gov/governance#core-types`)* +- Calls canonical pipelines: +- New service? *(if yes: Pentad scaffolding required at Phase 5)* + +## Commits + +### Commit 1: +**Files:** +**What:** +**Tests:** +**Canon citations needed:** + +### Commit 2: +… +``` + +## Validation gates (PRODUCT-level, not local hooks) + +Before declaring this phase complete, the plan MUST: + +- [ ] Have ZERO `[NEEDS_CLARIFICATION]` markers. +- [ ] If touching entity types, list ALL FIVE in any validation regex/map (P/L/T/E/A — never omit Authority). +- [ ] If creating a new service, declare full Pentad in commit list. +- [ ] If calling external services, cite their Charter URI. +- [ ] If the work writes to R2, declare which canonical pipeline (NOT `rclone copy`, NOT `wrangler r2 object put` — these would fail the canonical-pipeline check). + +## Output Contract + +```json +{ + "phase": "plan", + "status": "completed", + "plan_doc": "chittycontext/structured-autonomy//plan.md", + "commits": , + "new_service": , + "entity_types_touched": ["P", ...], + "canonical_pipelines_used": ["/documents", ...], + "chronicle_entry": "" +} +``` diff --git a/plugins/chittyagent-autobot/gemini-skills/chitty-autonomy-ship/SKILL.md b/plugins/chittyagent-autobot/gemini-skills/chitty-autonomy-ship/SKILL.md new file mode 100644 index 0000000..9bbfa55 --- /dev/null +++ b/plugins/chittyagent-autobot/gemini-skills/chitty-autonomy-ship/SKILL.md @@ -0,0 +1,70 @@ +--- +name: chitty-autonomy-ship +description: Phase 9 — Ship. Pushes branch, opens PR, blocks ship until Pentad complete for new services. Updates ChittyRegistry. Syncs canonical Notion entry. Finalizes ChittyChronicle. Auto-merge if repo policy allows AND all checks green AND cert still valid. +canonical_uri: chittycanon://skills/chitty-autonomy-ship +status: DRAFT +--- + +# Phase 9: Ship + +## Pre-ship gates (HARD) + +- Cert valid. +- All commits made; working tree clean. +- New service? Pentad complete (CHARTER + CHITTY + CLAUDE + SECURITY + AGENTS — schema-validated). +- Phase 6 review findings resolved or explicitly waived in cert metadata. +- Tests passing on current commit (re-run; do not trust earlier state). + +If any gate fails, return to the prior phase. + +## Process + +1. `git push -u origin ` +2. Build PR body referencing cert_id, chronicle entries, canonical pipelines used, Pentad status. +3. `gh pr create` with conventional title. +4. Registry update for new services: `POST registry.chitty.cc/api/services` with CHARTER URI + tier + domain. +5. Notion sync: Projects DB entry created/updated with PR URL, status, cert ID. Actions DB entry for follow-ups. +6. Auto-merge if repo allows squash-and-merge AND all checks green AND cert valid: `gh pr merge --auto --squash`. +7. Emit final ChittyChronicle entry. + +## PR body template + +```markdown +## Summary + + +## Sovereignty Affirmation +- Cert: (issued , expires ) +- Synthetic entity: +- Scope: feat=, branch= +- Sovereignty: type= level= + +## Canonical alignment +- Entity types touched (P/L/T/E/A): (cited via `// @canon:` in code) +- Canonical pipelines used: +- Pentad status (if new service): CHARTER ✓ CHITTY ✓ CLAUDE ✓ SECURITY ✓ AGENTS ✓ + +## Test plan +- [ ] + +## ChittyChronicle entries +- chittycanon://docs/audit//affirm +- chittycanon://docs/audit//commit-1 +- ... + +🤖 Generated by chittyagent-autobot +``` + +## Output Contract + +```json +{ + "phase": "ship", + "status": "shipped|merged", + "pr_url": "", + "auto_merge_enabled": false, + "registry_updated": false, + "notion_entry": "", + "chronicle_final_entry": "" +} +``` diff --git a/plugins/chittyagent-autobot/gemini-skills/chitty-autonomy-tidy/SKILL.md b/plugins/chittyagent-autobot/gemini-skills/chitty-autonomy-tidy/SKILL.md new file mode 100644 index 0000000..51f1d7f --- /dev/null +++ b/plugins/chittyagent-autobot/gemini-skills/chitty-autonomy-tidy/SKILL.md @@ -0,0 +1,42 @@ +--- +name: chitty-autonomy-tidy +description: Phase 7 — Auto-tidy. Runs format/lint sweep, branch cleanup (gone-tracking branches removed), invokes chitty-cleanup for local machine, runs wrangler-audit if Workers were touched, removes dead code per silent-failure-hunter findings. +canonical_uri: chittycanon://skills/chitty-autonomy-tidy +status: DRAFT +--- + +# Phase 7: Tidy + +## Process + +1. Verify cert valid. +2. **Format/lint sweep** — repo-wide: + - `npm run format` / `prettier --write .` (JS/TS) + - `npm run lint -- --fix` / `eslint --fix .` + - language-appropriate equivalents (`go fmt ./...`, `cargo fmt`, `ruff check --fix`, etc.) +3. **Branch cleanup** — invoke `commit-commands:clean_gone` skill (removes branches marked `[gone]` after upstream deletion). +4. **Local machine cleanup** — invoke `chitty-cleanup` skill (clears regenerable caches; respects user'\''s prior preferences). +5. **Wrangler audit** — if `wrangler.toml` / `wrangler.jsonc` files were touched, invoke `wrangler-audit` skill (consistency, stale compatibility dates, missing tail consumers, binding gaps). +6. **Dead-code sweep** — re-run `feature-dev:code-reviewer` confidence-filtered to `silent-failure-hunter` patterns; surface findings. +7. **Memory hygiene** — drop session-temporary memories; verify project memories are still relevant. +8. Emit ChittyChronicle entry. + +## Constraints + +- Format/lint changes that aren'\''t auto-applicable should be surfaced as review issues, not blanket-disabled. +- DO NOT auto-delete files outside the project repo (other than caches managed by chitty-cleanup). +- DO NOT rewrite git history (no rebase, no force-push). + +## Output Contract + +```json +{ + "phase": "tidy", + "status": "completed", + "format_changes": , + "branches_pruned": , + "wrangler_audit": {"passed": , "findings": [...]}, + "dead_code_findings": [...], + "chronicle_entry": "" +} +``` diff --git a/plugins/chittyagent-autobot/gemini-skills/chitty-autonomy/SKILL.md b/plugins/chittyagent-autobot/gemini-skills/chitty-autonomy/SKILL.md new file mode 100644 index 0000000..a6bde15 --- /dev/null +++ b/plugins/chittyagent-autobot/gemini-skills/chitty-autonomy/SKILL.md @@ -0,0 +1,114 @@ +--- +name: chitty-autonomy +description: ChittyOS-canonical autonomous PR-driver. One-stop workflow that orchestrates Sovereignty → Discover → Brainstorm → Plan → Generate → Implement → Review → Tidy → CI/CD → Ship → Memory. Issues a SOVEREIGNTY.cert from ChittyCert at start; Pentad-aware (CHARTER+CHITTY+CLAUDE+SECURITY+AGENTS); enforces canonical pipelines (no rclone-bypass, no direct R2 writes); writes ChittyChronicle audit entries per phase. Triggered by `/autonomy ` or by-hand invocation. +canonical_uri: chittycanon://skills/chitty-autonomy +status: DRAFT +sovereignty_cert_required: true +sovereignty_cert_issuer: chittycanon://core/services/chitty-cert +--- + +# Chitty Autonomy — Parent Orchestrator + +## Purpose + +Drive a feature request from one-line prompt to merged PR with full ChittyOS canonical compliance. This is the SUCCESSOR to the `structured-autonomy-{plan,generate,implement}` trio. It addresses three classes of defect in the original: + +1. **Tool-syntax debt** (`#tool:runSubagent`, `#context7`, `ResizeMe` Windows references). +2. **Governance blindness** (no ChittyRegistry discovery, no canon citations, no `chittyagent-canon` review). +3. **No state machine** (three skills that don't compose; no failure recovery). + +## Sovereignty Affirmation (Phase 0 — MANDATORY) + +Before any other work, the synthetic entity (this Claude context) MUST request a Sovereignty Affirmation certificate from ChittyCert. + +``` +POST https://mychitty.com/api/v1/identity/api/v1/issue +{ + "type": "TRUST_CHAIN", + "subject_chitty_id": "", + "subject_type": "P", + "subject_status": "Operational", + "purpose": "synthetic-entity-sovereignty-affirmation", + "scope": { + "feature": "", + "branch": "", + "repo": "", + "valid_until": "" + }, + "constraints": [ + "Cannot bypass canonical pipelines (POST /collect, /documents, /vault/ingest)", + "Must cite chittycanon:// URIs when defining/validating entity types (P/L/T/E/A — all five)", + "Must consult ChittyRegistry before scaffolding new services", + "Must require Pentad (CHARTER, CHITTY, CLAUDE, SECURITY, AGENTS) for new services", + "Must emit ChittyChronicle audit entry per phase boundary" + ], + "ledger_anchor": "chittycanon://core/services/chittychronicle" +} +``` + +Response payload is persisted to `chittycontext/structured-autonomy//SOVEREIGNTY.cert` and referenced by `cert_id` in every subsequent phase output. If issuance fails, abort the whole workflow — **the agent does not act without affirmation**. + +> **Note:** The `TRUST_CHAIN` tier is the closest existing fit. A formal `SOVEREIGNTY_AFFIRMATION` tier should be proposed to the ChittyCert charter as a follow-up issue. + +## Phase Pipeline + +| # | Phase | Skill | Output | +|---|---|---|---| +| 0 | Sovereignty | `chitty-autonomy-affirm` | `SOVEREIGNTY.cert` (signed by ChittyCert) | +| 1 | Discover | `chitty-autonomy-discover` | `chittycontext/.../discovery.md` (registry + Pentad reads) | +| 2 | Brainstorm | `superpowers:brainstorming` (delegated) | conversation context | +| 3 | Plan | `chitty-autonomy-plan` | `plan.md` with [NEEDS_CLARIFICATION] markers enforced | +| 4 | Generate | `chitty-autonomy-generate` | `implementation.md` with copy-paste TDD-aware code | +| 5 | Implement | `chitty-autonomy-implement` | committed code, format/lint inline | +| 6 | Review | delegate to `chittyagent-canon` + `code-reviewer` + `silent-failure-hunter` + `comment-analyzer` | review report; gate to next phase | +| 7 | Tidy | `chitty-autonomy-tidy` | branch-cleanup, format, lint, chitty-cleanup invocation | +| 8 | CI/CD | `chitty-autonomy-cicd` | `.github/workflows/`, wrangler deploy targets, secrets scaffold | +| 9 | Ship | `chitty-autonomy-ship` | PR created/auto-merged, ChittyRegistry update, Notion sync | +| 10 | Memory | inline | feedback/project memory written; ChittyChronicle finalize entry | + +## State Machine + +State persisted at `chittycontext/structured-autonomy//state.json`: +```json +{ + "feature": "", + "branch": "", + "cert_id": "", + "phase": "discover|plan|generate|implement|review|tidy|cicd|ship|memory|done", + "started_at": "", + "phase_history": [ + { "phase": "affirm", "completed_at": "", "chronicle_entry": "" } + ] +} +``` + +Survives session restarts. On re-invocation, parent reads state and resumes at `phase + 1`. + +## Product-Level Enforcement (NOT Claude Code hooks) + +- **ChittyChronicle** entry per phase boundary (`chittycanon://docs/audit//`). +- **ChittyRegistry** register/update on Phase 9 for new services. +- **ChittyCert verify** call at start of phases 5, 8, 9 (sanity check the affirmation is still valid). +- **Canonical-URI cite** in generated code: `// @canon: chittycanon://...`. +- **Pentad presence check** for new services via Phase 9 ship gate (refuses to ship without all five). + +## Inputs + +- Argument: `` (free-form natural-language description) +- Optional flags: + - `--tdd` — force test-driven path through Phases 4-5 + - `--service ` — scaffold a new ChittyOS service (full Pentad) + - `--resume` — re-enter the state machine at last incomplete phase + - `--skip-discover` (REQUIRES justification stored in cert metadata) + +## Failure Modes + +- **Cert refused or expired** → abort; emit ChittyChronicle `affirmation_denied` entry; report to user. +- **[NEEDS_CLARIFICATION] still present at Phase 4 entry** → return to Phase 3, request clarification. +- **Hookify rule pattern detected in generated code** (e.g., `rclone copy` to evidence buckets) → return to Phase 4 with corrective instruction. +- **Pentad incomplete on a NEW service at Phase 9** → block ship; loop back to Phase 5. +- **Test failure at Phase 5** → invoke `superpowers:systematic-debugging`; do not advance. + +## Hand-off Discipline + +The parent skill ONLY orchestrates. Each phase is a child skill or delegated agent. The parent does not write code, run tests, or execute git commands directly — it picks the next phase, invokes the correct skill, captures output, and updates state. diff --git a/plugins/chittyagent-dispatch/scripts/adapters/claude-code-mcp.sh b/plugins/chittyagent-dispatch/scripts/adapters/claude-code-mcp.sh index d2cd49e..bf7a604 100755 --- a/plugins/chittyagent-dispatch/scripts/adapters/claude-code-mcp.sh +++ b/plugins/chittyagent-dispatch/scripts/adapters/claude-code-mcp.sh @@ -55,7 +55,7 @@ if not mcp or not isinstance(mcp, dict): sys.exit("canonical missing mcp: block (command/args/env)") # Read existing .mcp.json if present, else start fresh. -if os.path.exists(out_path): +if os.path.exists(out_path) and os.path.getsize(out_path) > 0: with open(out_path, encoding="utf-8") as f: existing = json.load(f) else: diff --git a/plugins/chittyagent-dispatch/scripts/adapters/gemini-skill.sh b/plugins/chittyagent-dispatch/scripts/adapters/gemini-skill.sh new file mode 100755 index 0000000..1d35d29 --- /dev/null +++ b/plugins/chittyagent-dispatch/scripts/adapters/gemini-skill.sh @@ -0,0 +1,81 @@ +#!/usr/bin/env bash +# gemini-skill.sh — project a canonical agent definition to a Gemini SKILL.md. +# +# Usage: +# gemini-skill.sh +# +# Behavior: +# - Strict YAML round-trip via PyYAML. Canonical descriptions MUST use a block +# scalar (`description: |`) — see canonical/README.md. +# - Strips canonical-only top-level keys (kind, classification, runtimes, +# plugin, runtime_overrides) AND Claude Code-only keys (model, color, tools) +# since Gemini SKILL.md frontmatter only honors name + description (+ gemini +# overrides). +# - Merges runtime_overrides.gemini into projected frontmatter. +# - Idempotent: stable key order, no timestamps in output. +set -euo pipefail + +canonical="${1:-}" +out="${2:-}" +[ -n "$canonical" ] && [ -n "$out" ] || { echo "usage: $0 " >&2; exit 2; } +[ -f "$canonical" ] || { echo "canonical not found: $canonical" >&2; exit 2; } + +mkdir -p "$(dirname "$out")" + +python3 - "$canonical" "$out" <<'PY' +import sys, re, yaml + +canonical_path, out_path = sys.argv[1], sys.argv[2] +src = open(canonical_path, "r", encoding="utf-8").read() + +m = re.match(r"^---\n(.*?\n)---\n(.*)$", src, re.DOTALL) +if not m: + sys.exit(f"no frontmatter in {canonical_path}") + +try: + fm = yaml.safe_load(m.group(1)) or {} +except yaml.YAMLError as e: + sys.exit( + f"canonical frontmatter is not valid YAML: {e}\n" + f"Hint: descriptions with prose/colons/ blocks must use a block scalar:\n" + f" description: |\n" + f" Your prose here..." + ) +body = m.group(2).lstrip("\n") + +for req in ("name", "description"): + if not fm.get(req): + sys.exit(f"canonical missing required field: {req}") + +CANONICAL_ONLY = {"kind", "classification", "runtimes", "plugin", "runtime_overrides"} +CLAUDE_CODE_ONLY = {"model", "color", "tools"} +STRIP = CANONICAL_ONLY | CLAUDE_CODE_ONLY + +overrides = (fm.get("runtime_overrides") or {}).get("gemini") or {} +projected = {k: v for k, v in fm.items() if k not in STRIP} +projected.update(overrides) + +# Stable order: Gemini SKILL.md convention puts name first, description second. +preferred = ["name", "description"] +ordered = {k: projected[k] for k in preferred if k in projected} +for k, v in projected.items(): + if k not in ordered: + ordered[k] = v + +class BlockStr(str): + pass + +def block_str_representer(dumper, data): + return dumper.represent_scalar("tag:yaml.org,2002:str", data, style="|") + +yaml.add_representer(BlockStr, block_str_representer) + +for k, v in list(ordered.items()): + if isinstance(v, str) and "\n" in v: + ordered[k] = BlockStr(v) + +fm_yaml = yaml.dump(ordered, sort_keys=False, default_flow_style=False, allow_unicode=True, width=100000).rstrip() + "\n" +open(out_path, "w", encoding="utf-8").write(f"---\n{fm_yaml}---\n\n{body}") +PY + +echo "[gemini-skill] projected $canonical -> $out" diff --git a/plugins/chittyagent-dispatch/scripts/lib/audit.py b/plugins/chittyagent-dispatch/scripts/lib/audit.py index f07f3a8..ea77f5e 100755 --- a/plugins/chittyagent-dispatch/scripts/lib/audit.py +++ b/plugins/chittyagent-dispatch/scripts/lib/audit.py @@ -29,6 +29,11 @@ sys.path.insert(0, os.path.dirname(__file__)) from resolve_output import resolve, _MAP # noqa: E402 +# Generated-only projection dirs, derived from _MAP so a new runtime cannot +# reopen the ORPHAN_PROJ blind spot. claude-code writes to shared dirs +# (agents/skills/commands/hooks/.mcp.json), so it is excluded. +_GENERATED_DIRS = sorted({t.split("/")[2] for (rt, _k), (t, _a) in _MAP.items() if rt != "claude-code"}) + try: import yaml except ImportError: @@ -170,7 +175,7 @@ def audit(repo_root): if not os.path.isdir(pdir): continue # Only audit projection dirs that are exclusively generated outputs. - for rel in ("codex-skills", "openclaw-agents", "claude-skills", "chatgpt-apps"): + for rel in _GENERATED_DIRS: proj_root = os.path.join(pdir, rel) if not os.path.isdir(proj_root): continue diff --git a/plugins/chittyagent-dispatch/scripts/lib/resolve_output.py b/plugins/chittyagent-dispatch/scripts/lib/resolve_output.py index 245ecca..a00b281 100755 --- a/plugins/chittyagent-dispatch/scripts/lib/resolve_output.py +++ b/plugins/chittyagent-dispatch/scripts/lib/resolve_output.py @@ -25,6 +25,8 @@ ("claude-code", "mcp-server"): ("plugins/{plugin}/.mcp.json", "claude-code-mcp.sh"), ("codex", "agent"): ("plugins/{plugin}/codex-skills/{name}/SKILL.md", "codex-skill.sh"), ("codex", "skill"): ("plugins/{plugin}/codex-skills/{name}/SKILL.md", "codex-skill.sh"), + ("gemini", "agent"): ("plugins/{plugin}/gemini-skills/{name}/SKILL.md", "gemini-skill.sh"), + ("gemini", "skill"): ("plugins/{plugin}/gemini-skills/{name}/SKILL.md", "gemini-skill.sh"), ("openclaw", "agent"): ("plugins/{plugin}/openclaw-agents/{name}.yaml", "openclaw-agent.sh"), ("claude-skills", "tool"): ("plugins/{plugin}/claude-skills/{name}.json", "claude-skills.sh"), ("chatgpt-apps", "tool"): ("plugins/{plugin}/chatgpt-apps/{name}.json", "chatgpt-apps.sh"), diff --git a/plugins/chittyagent-dispatch/scripts/pre-commit-drift.sh b/plugins/chittyagent-dispatch/scripts/pre-commit-drift.sh index 5b3a681..c5c650f 100755 --- a/plugins/chittyagent-dispatch/scripts/pre-commit-drift.sh +++ b/plugins/chittyagent-dispatch/scripts/pre-commit-drift.sh @@ -37,7 +37,7 @@ for f in "${staged[@]}"; do [ "$n" = "README" ] || names["$n"]=1 ;; plugins/*/agents/*.md) n="${f##*/}"; names["${n%.md}"]=1 ;; - plugins/*/codex-skills/*/SKILL.md) + plugins/*/codex-skills/*/SKILL.md|plugins/*/gemini-skills/*/SKILL.md) tmp="${f%/SKILL.md}"; names["${tmp##*/}"]=1 ;; plugins/*/openclaw-agents/*.yaml) n="${f##*/}"; names["${n%.yaml}"]=1 ;; diff --git a/plugins/chittymarket-manager/gemini-skills/market/SKILL.md b/plugins/chittymarket-manager/gemini-skills/market/SKILL.md new file mode 100644 index 0000000..b46a9c0 --- /dev/null +++ b/plugins/chittymarket-manager/gemini-skills/market/SKILL.md @@ -0,0 +1,159 @@ +--- +name: market +description: ChittyMarket artifact manager — list, enable, disable, sync, and configure install mode for skills, agents, MCP servers, plugins, and hooks via the /market command. +canon_uri: chittycanon://core/services/chittymarket#skills/market +--- + +# /market — ChittyMarket Artifact Manager + +Manage all Claude Code artifacts (MCP servers, skills, plugins, agents, hooks) from a single interface. + +## Triggers + +- User types `/market` +- User mentions "marketplace", "market list", "market enable", "market disable" + +## Arguments + +- `/market` or `/market list` — List all artifacts grouped by type +- `/market list --type=` — Filter by type (mcp-server, skill, plugin, agent, hook) +- `/market list --category=` — Filter by category (ecosystem, code, search, legal, etc.) +- `/market list --enabled` — Show only enabled artifacts +- `/market list --disabled` — Show only disabled artifacts +- `/market enable ` — Enable an artifact +- `/market disable ` — Disable an artifact +- `/market info ` — Show artifact details (incl. provenance status) +- `/market verify [|--all]` — Verify capability-record provenance (content_hash) +- `/market mode ch1tty|standalone` — Switch install mode +- `/market sync` — Scan filesystem and reconcile manifest with actual state + +## Provenance (verify-on-enable) + +Every capability has a content-addressed record in `capabilities.generated.json` +(SHA-256 `content_hash`; see `docs/architecture/CAPABILITY_PROVENANCE.md`). +`enable` is **fail-closed**: if an artifact's record fails its `content_hash` +(tampered/stale), activation is blocked unless `MARKET_SKIP_VERIFY=1`. `verify` +audits one or all records; `info` shows provenance status. Signatures +(`signer_chittyid`) are surfaced when present — pending Layer 2 they read +"unsigned — signature pending". + +## Manifest Location + +The single source of truth is: `~/.claude/marketplace.json` +(Symlinked from `/Users/nb/Desktop/Projects/github.com/CHITTYOS/chittymarket/marketplace.json`) + +## Shell Actuator + +A shell script at `~/.claude/skills/market/market.sh` handles all commands. **Use this script for all operations** instead of manually reading/editing JSON files. + +```bash +~/.claude/skills/market/market.sh list # List all +~/.claude/skills/market/market.sh list --type=skill # Filter by type +~/.claude/skills/market/market.sh list --category=code # Filter by category +~/.claude/skills/market/market.sh list --enabled # Only enabled +~/.claude/skills/market/market.sh list --disabled # Only disabled +~/.claude/skills/market/market.sh enable # Enable artifact +~/.claude/skills/market/market.sh disable # Disable artifact +~/.claude/skills/market/market.sh info # Show details + provenance +~/.claude/skills/market/market.sh verify [|--all] # Verify content_hash provenance +~/.claude/skills/market/market.sh sync # Reconcile with filesystem +``` + +When this skill is triggered, run the appropriate `market.sh` command via Bash. Display the output to the user. For `/market mode`, fall back to the manual instructions below since `market.sh` doesn't implement mode switching yet. + +## Manual Instructions (fallback) + +If `market.sh` is unavailable, read `~/.claude/marketplace.json` and execute the requested command manually. + +### `/market list` + +1. Read `~/.claude/marketplace.json` +2. Filter out `_comment` entries +3. Group artifacts by `type` +4. For each artifact, display: + ``` + [ON] serena Read and Write Source Code mcp-server code ch1tty+standalone + [OFF] plugin-github GitHub plugin code standalone + ``` +5. If `--type=X` is provided, only show that type +6. If `--category=X` is provided, only show that category +7. Show summary counts at the bottom + +### `/market enable ` + +1. Read marketplace.json, find artifact by `id` +2. If already enabled, inform user +3. Apply the toggle based on artifact type: + +| Type | How to Enable | +|------|--------------| +| `mcp-server` | Read Ch1tty's `servers.json` at `/Users/nb/Desktop/Projects/github.com/CHITTYOS/ch1tty/servers.json`. Find the server entry matching the artifact's `ch1tty.serverId`. Set `"enabled": true`. | +| `skill` | Check if `SKILL.md.disabled` exists at the skill path. If so, rename it to `SKILL.md` using: `mv /SKILL.md.disabled /SKILL.md` | +| `plugin` (official) | Read `~/.claude/settings.json`. In the `enabledPlugins` map, set the plugin ref to `true`. | +| `plugin` (local) | Read `~/.claude/plugins/blocklist.json`. Remove the entry matching this plugin from the `plugins` array. | +| `agent` | Check if `.md.disabled` exists. If so, rename to `.md` | +| `hook` (hookify) | Read the hookify rule `.md` file. In the YAML frontmatter, set `enabled: true` | + +4. Update `"enabled": true` in marketplace.json +5. Confirm to user + +### `/market disable ` + +1. Read marketplace.json, find artifact by `id` +2. If already disabled, inform user +3. Apply the toggle based on artifact type: + +| Type | How to Disable | +|------|---------------| +| `mcp-server` | In Ch1tty's `servers.json`, set `"enabled": false` for the matching server entry | +| `skill` | Rename `SKILL.md` to `SKILL.md.disabled` at the skill path | +| `plugin` (official) | In `~/.claude/settings.json` `enabledPlugins`, set the ref to `false` | +| `plugin` (local) | Add entry to `~/.claude/plugins/blocklist.json` with reason "disabled-via-market" | +| `agent` | Rename `.md` to `.md.disabled` | +| `hook` (hookify) | In the hookify rule, set `enabled: false` in YAML frontmatter | + +4. Update `"enabled": false` in marketplace.json +5. Confirm to user + +### `/market info ` + +1. Find the artifact in marketplace.json +2. Display all fields in a readable format: + - Name, description, type, category, access + - Enabled status + - Install mode (ch1tty / standalone / both) + - Tags + - Standalone details (ref or path) + - Ch1tty details (serverId if applicable) + +### `/market mode ch1tty|standalone` + +1. Find the artifact in marketplace.json +2. Verify the requested mode is available (check `standalone.available` or `ch1tty.available`) +3. If switching to ch1tty: disable standalone install, enable in Ch1tty servers.json +4. If switching to standalone: disable in Ch1tty servers.json, enable standalone install +5. Update `installMode` in marketplace.json +6. Confirm to user + +### `/market sync` + +Reconcile marketplace.json with actual filesystem state: + +1. **MCP Servers**: Read Ch1tty servers.json, compare `enabled` field +2. **Skills**: Check each skill path — if `SKILL.md` exists it's enabled, if `SKILL.md.disabled` exists it's disabled +3. **Official Plugins**: Read `~/.claude/settings.json` `enabledPlugins` map +4. **Local Plugins**: Check `~/.claude/plugins/blocklist.json` +5. **Agents**: Check if `.md` or `.md.disabled` exists +6. **Hooks**: Check hookify rule frontmatter for `enabled` field + +For any discrepancies, update marketplace.json to match actual state. Report what changed. + +## Key File Paths + +- Marketplace manifest: `~/.claude/marketplace.json` +- Ch1tty servers: `/Users/nb/Desktop/Projects/github.com/CHITTYOS/ch1tty/servers.json` +- Settings: `~/.claude/settings.json` +- Plugin blocklist: `~/.claude/plugins/blocklist.json` +- Skills: `~/.claude/skills//SKILL.md` +- Agents: `~/.claude/agents/.md` +- Hooks: `~/.claude/hooks/hookify..local.md` diff --git a/plugins/chittyos-core/codex-skills/chico/SKILL.md b/plugins/chittyos-core/codex-skills/chico/SKILL.md index d3b81f3..9cd43af 100644 --- a/plugins/chittyos-core/codex-skills/chico/SKILL.md +++ b/plugins/chittyos-core/codex-skills/chico/SKILL.md @@ -1,18 +1,18 @@ --- name: chico -description: Shortcut to dispatch the ChittyConnect concierge (chittyos-core/chittyconnect-concierge) — the canonical owner of credentials, connections, secret rotation, KV/D1 bindings, and ChittyConnect-side wiring. Triggers on "/chico", "/chico-keys", or when the user wants to invoke the concierge by its nickname. The concierge handles ChittySecrets resolution, wrangler secret put, CF API token rotation, binding restore, deploy-time binding audits, and anything in the credential lane. The operator (user) is OPERATOR ONLY — never asked to paste a secret; route through chico-keys. +description: Shortcut to dispatch the ChittyConnect concierge (chittyos-core:chittyagent-connect) — the canonical owner of credentials, connections, secret rotation, KV/D1 bindings, and ChittyConnect-side wiring. Triggers on "/chico", "/chico-keys", or when the user wants to invoke the concierge by its nickname. The operator is OPERATOR ONLY — never asked to paste a secret; route through chico-keys. canon_uri: chittycanon://core/services/chittymarket#skills/chico --- # /chico — ChittyConnect Concierge Alias -The user invoked `/chico` to dispatch the **chittyos-core:chittyconnect-concierge** agent (nickname: "chico-keys"). Treat the rest of the user's message as the task brief for the concierge. +The user invoked `/chico` to dispatch the **chittyos-core:chittyagent-connect** agent (nickname: "chico-keys"). Treat the rest of the user's message as the task brief for the concierge. ## What to do 1. Read the user's arguments / message body — that's the brief. 2. Dispatch the concierge via the Task tool with: - - `subagent_type: "chittyos-core:chittyconnect-concierge"` + - `subagent_type: "chittyos-core:chittyagent-connect"` - `description`: a 3-5 word summary of the task - `prompt`: the user's brief, expanded with the standing constraints below if needed - `run_in_background: true` for longer credential/deploy work; foreground for quick lookups @@ -22,11 +22,13 @@ The user invoked `/chico` to dispatch the **chittyos-core:chittyconnect-concierg These are binding for every chico-keys invocation: -- **The operator is OPERATOR ONLY** — never asked to paste/provide/rotate any credential value. If a value is needed, it is resolved through **ChittySecrets** (`secrets.chitty.cc`, fronting the Cloudflare Secrets Store) by the concierge. 1Password / `op` is RETIRED — never invoke it. +- **The operator is OPERATOR ONLY** — never asked to paste/provide/rotate any credential value. If a value is needed, resolve it through the ChittyConnect / ChittySecrets broker lane (concierge's job). Do NOT use `op` / 1Password on this host: it has zero accounts configured (`op account list` returns empty), so every `op read` / `op run` fails. - **Real validation only** — no mocks, no placeholder values, no "would-be" config. Concrete evidence (curl output, deploy version id, audit script result). - **Safe deploy only** — bare `wrangler deploy` is the documented anti-pattern (see chittyconnect#217/#221, chittyentity#324/#315). Always `--env production` (or staging), routed through `safe-deploy.sh` if the worker has one. - **Operator approval required** for: production deploys of new (not yet shipped) code, secret rotations affecting org-wide auth, anything irreversible without rollback. Surface for go/no-go; do not auto-execute. -- **If genuinely blocked** (secret absent from ChittySecrets, CF Access denied, cross-cutting policy) → STOP and file a follow-up issue on the right repo (chittyconnect, chittyentity, etc.). Do NOT route the blocker back to the operator as a credential ask. +- **A non-functional `op` / 1Password lane is an EXPECTED host condition** — never a finding, never a blocker, and never grounds for filing a follow-up issue. Use the broker lane instead. +- **If the broker path is unavailable** (ChittyConnect / ChittySecrets unreachable, unauthenticated, or refusing) → **fail closed and loud**: emit the literal token `POLICY_BLOCKED_CHITTYCONNECT_UNAVAILABLE` in the concierge report so it is greppable, and stop. Never silently fall back to a local credential lane, and never substitute a placeholder value. +- **If genuinely blocked** for any other reason (cross-cutting policy, missing authorization, ambiguous scope) → STOP and file a follow-up issue on the right repo (chittyconnect, chittyentity, etc.). Do NOT route the blocker back to the operator as a credential ask. ## When NOT to use /chico @@ -37,12 +39,12 @@ These are binding for every chico-keys invocation: ## Examples - `/chico restore chittyconnect bindings` → dispatch concierge to inspect deployed bindings, restore any missing via safe-deploy, audit post-deploy. -- `/chico rotate CF token #215` → dispatch concierge to handle CF API token rotation (chittyconnect#215), through ChittySecrets + gh secret set, no operator credential asking. +- `/chico rotate CF token #215` → dispatch concierge to handle CF API token rotation (chittyconnect#215), through the ChittyConnect broker lane + gh secret set, no operator credential asking. - `/chico claim Action 1b 2aacb316` → dispatch concierge to claim the chittyagent-tasks task `2aacb316` (ChittyConnect neon_auth readiness PR) via `tasks_claim`, execute, then `tasks_complete`. - `/chico audit deployed bindings` → dispatch concierge for a one-shot drift audit across the chittyconnect / chittyagent-viewport / chittyagent-* workers using their safe-deploy scripts. ## Where the concierge lives -- Plugin id: `chittyos-core:chittyconnect-concierge` -- Lane: credentials, connections, secrets, ChittySecrets, wrangler secrets, CF tokens, KV/D1 bindings, deploy hygiene. +- Plugin id: `chittyos-core:chittyagent-connect` +- Lane: credentials, connections, secrets, ChittyConnect/ChittySecrets brokering, wrangler secrets, CF tokens, KV/D1 bindings, deploy hygiene. - Memory alias: "chico-keys" (saved in [[orchestrate-via-systems]]). diff --git a/plugins/chittyos-core/codex-skills/nb-development-defaults/SKILL.md b/plugins/chittyos-core/codex-skills/nb-development-defaults/SKILL.md index d5626bd..56b1aed 100644 --- a/plugins/chittyos-core/codex-skills/nb-development-defaults/SKILL.md +++ b/plugins/chittyos-core/codex-skills/nb-development-defaults/SKILL.md @@ -409,17 +409,40 @@ Every dispatched subagent should default to `ch1tty/cast` for orchestration and ## Workers Builds (CF CI/CD) -All ChittyOS workers deploy via Cloudflare Workers Builds (git-triggered). Config is managed via API, not dashboard. +Cloudflare Workers Builds is the normal build and deployment path for ChittyOS workers. +GitHub remains the source-control and review surface; it is not a second deployment +system. Configure Workers Builds through the API, not the dashboard. - **API base**: `https://api.cloudflare.com/client/v4/accounts/{ACCOUNT_ID}/builds/` - **Auth**: `Authorization: Bearer {cfut_ account token}` — needs "Workers Builds Configuration:Edit" permission - **Script ID**: Use script TAG (not name). Get via `GET /workers/services/{name}` → `.result.default_environment.script_tag` - **Triggers**: Each worker has 2 (production branch + non-production). PATCH to update, POST to create. - **Key endpoints**: `/builds/triggers` (CRUD), `/builds/workers/{script_tag}/triggers` (list), `/builds/triggers/{uuid}/builds` (manual trigger) -- **Pattern**: Workers with `env.production` blocks deploy via `npx wrangler deploy --env production` +- **Normal path**: a push to the configured branch triggers the Cloudflare Workers Build + and deployment. +- **Wrangler**: use `npx wrangler deploy --env production` for local development, + `--dry-run` validation, or an explicitly approved emergency/manual deployment only. + Do not run Wrangler deployment in parallel with the Workers Build for the same commit. - **Shared deps**: Workers importing from `../shared/` use build command `cd ../shared && npm ci` - **Watch paths**: Shared importers watch both `/workers/{name}/*` and `/workers/shared/*` +### GitHub free-tier operating model + +Keep GitHub Actions lightweight and non-duplicative. Repository workflows should do +only inexpensive validation such as lint, typecheck, unit tests, and configuration +checks. Full builds and deployments belong to Cloudflare Workers Builds unless a +repository has an explicitly documented exception. + +- Do not duplicate a Cloudflare deployment in GitHub Actions. +- Do not assume paid GitHub features, unlimited minutes, required reviewers, or + auto-merge are available. +- Prefer one small repository workflow template over large, frequently changing + workflow copies. +- Treat the Cloudflare build result as the deployment gate and record the build URL + or ID in the release/incident note when operational evidence is needed. +- Use path filters and branch filters so unrelated repository changes do not trigger + Worker builds. + ## Review and Audit Bias - For review requests, findings come first. diff --git a/plugins/chittyos-core/gemini-skills/checkpoint/SKILL.md b/plugins/chittyos-core/gemini-skills/checkpoint/SKILL.md new file mode 100644 index 0000000..fea910c --- /dev/null +++ b/plugins/chittyos-core/gemini-skills/checkpoint/SKILL.md @@ -0,0 +1,133 @@ +--- +name: checkpoint +description: Save or resume session state. Use /checkpoint to save progress at session end, or /checkpoint resume to reload prior session state at session start. Triggers on "checkpoint", "save progress", "session state", "where did I leave off", "resume", "pick up where I left off". +canon_uri: chittycanon://core/services/chittymarket#skills/checkpoint +--- + +# Session Checkpoint + +Persist session state so the next session can resume without losing context. + +## Usage + +- `/checkpoint` or `/checkpoint save` — Save current session state +- `/checkpoint resume` — Load most recent checkpoint and resume work + +## Save Mode (default) + +When saving, create a checkpoint file at `~/.claude/checkpoints/{project-slug}-{date}.md` and update the latest pointer. + +### Step 1: Gather State + +Collect the following from the current session: + +1. **Working directory**: `pwd` +2. **Git state**: `git branch --show-current`, `git status --short`, `git log --oneline -5` +3. **Task list**: Check TaskList for any open/in-progress tasks +4. **Modified files**: `git diff --name-only` (unstaged) and `git diff --cached --name-only` (staged) +5. **What was discussed**: Summarize the key topics, decisions, and work done this session + +### Step 2: Write Checkpoint + +Write the checkpoint file: + +```markdown +# Session Checkpoint +**Date**: {YYYY-MM-DD HH:MM} +**Project**: {project name from directory} +**Branch**: {current git branch} +**Duration context**: {brief summary of session length/scope} + +## Accomplished +- {bullet list of what was completed} + +## In Progress +- {bullet list of unfinished work with specific file paths and line numbers} + +## Blocked / Issues +- {any blockers, environment issues, or unresolved problems} + +## Next Steps +1. {numbered list of what to do next, in priority order} +2. {include specific commands where helpful} + +## Modified Files (uncommitted) +{list from git diff} + +## Open Tasks +{from TaskList, if any} + +## Resume Commands +```bash +# Run these to get back to where you were: +cd {working directory} +git status +{any other setup commands} +``` +``` + +### Step 3: Update Latest Pointer + +```bash +# Create symlink or copy to "latest" for easy resume +cp checkpoint-file ~/.claude/checkpoints/{project-slug}-latest.md +``` + +### Step 4: Confirm + +Tell the user: "Checkpoint saved. Next session, run `/checkpoint resume` to pick up where you left off." + +--- + +## Resume Mode + +When the user says `/checkpoint resume` or "where did I leave off": + +### Step 1: Find Latest Checkpoint + +```bash +# Check for project-specific checkpoint first +PROJECT=$(basename "$(pwd)") +ls -t ~/.claude/checkpoints/${PROJECT}*-latest.md 2>/dev/null | head -1 + +# Fall back to most recent checkpoint +ls -t ~/.claude/checkpoints/*-latest.md 2>/dev/null | head -1 +``` + +### Step 2: Load and Present + +Read the checkpoint file and present a concise summary: + +``` +Resuming from checkpoint ({date}): + +**Last session**: {1-line summary} +**Branch**: {branch} | **Uncommitted**: {count} files +**Next steps**: +1. {first priority} +2. {second priority} + +Ready to continue? +``` + +### Step 3: Verify State + +Run the resume commands from the checkpoint to verify the environment matches: +- Check we're on the right branch +- Check uncommitted files still exist +- Check for any new changes since the checkpoint +- Flag any discrepancies (e.g., "Note: 3 files have changed since the checkpoint") + +### Step 4: Create Tasks + +If the checkpoint has "Next Steps", create TaskCreate entries for each one so progress is tracked. + +--- + +## Cleanup + +Checkpoints older than 14 days can be cleaned up: + +```bash +find ~/.claude/checkpoints -name "*.md" -not -name "*-latest.md" -mtime +14 -delete +``` diff --git a/plugins/chittyos-core/gemini-skills/chico/SKILL.md b/plugins/chittyos-core/gemini-skills/chico/SKILL.md new file mode 100644 index 0000000..9cd43af --- /dev/null +++ b/plugins/chittyos-core/gemini-skills/chico/SKILL.md @@ -0,0 +1,50 @@ +--- +name: chico +description: Shortcut to dispatch the ChittyConnect concierge (chittyos-core:chittyagent-connect) — the canonical owner of credentials, connections, secret rotation, KV/D1 bindings, and ChittyConnect-side wiring. Triggers on "/chico", "/chico-keys", or when the user wants to invoke the concierge by its nickname. The operator is OPERATOR ONLY — never asked to paste a secret; route through chico-keys. +canon_uri: chittycanon://core/services/chittymarket#skills/chico +--- + +# /chico — ChittyConnect Concierge Alias + +The user invoked `/chico` to dispatch the **chittyos-core:chittyagent-connect** agent (nickname: "chico-keys"). Treat the rest of the user's message as the task brief for the concierge. + +## What to do + +1. Read the user's arguments / message body — that's the brief. +2. Dispatch the concierge via the Task tool with: + - `subagent_type: "chittyos-core:chittyagent-connect"` + - `description`: a 3-5 word summary of the task + - `prompt`: the user's brief, expanded with the standing constraints below if needed + - `run_in_background: true` for longer credential/deploy work; foreground for quick lookups +3. When the concierge returns, summarize its report to the user. + +## Standing constraints to apply to any concierge dispatch + +These are binding for every chico-keys invocation: + +- **The operator is OPERATOR ONLY** — never asked to paste/provide/rotate any credential value. If a value is needed, resolve it through the ChittyConnect / ChittySecrets broker lane (concierge's job). Do NOT use `op` / 1Password on this host: it has zero accounts configured (`op account list` returns empty), so every `op read` / `op run` fails. +- **Real validation only** — no mocks, no placeholder values, no "would-be" config. Concrete evidence (curl output, deploy version id, audit script result). +- **Safe deploy only** — bare `wrangler deploy` is the documented anti-pattern (see chittyconnect#217/#221, chittyentity#324/#315). Always `--env production` (or staging), routed through `safe-deploy.sh` if the worker has one. +- **Operator approval required** for: production deploys of new (not yet shipped) code, secret rotations affecting org-wide auth, anything irreversible without rollback. Surface for go/no-go; do not auto-execute. +- **A non-functional `op` / 1Password lane is an EXPECTED host condition** — never a finding, never a blocker, and never grounds for filing a follow-up issue. Use the broker lane instead. +- **If the broker path is unavailable** (ChittyConnect / ChittySecrets unreachable, unauthenticated, or refusing) → **fail closed and loud**: emit the literal token `POLICY_BLOCKED_CHITTYCONNECT_UNAVAILABLE` in the concierge report so it is greppable, and stop. Never silently fall back to a local credential lane, and never substitute a placeholder value. +- **If genuinely blocked** for any other reason (cross-cutting policy, missing authorization, ambiguous scope) → STOP and file a follow-up issue on the right repo (chittyconnect, chittyentity, etc.). Do NOT route the blocker back to the operator as a credential ask. + +## When NOT to use /chico + +- Pure code work that doesn't touch credentials, secrets, bindings, or deploy → use a general-purpose agent. +- Verifying running services / probing endpoints → can be done directly (read-only) or with a general agent. +- Architecture decisions / refactors → concierge focuses on the credential + connection lane; pure design belongs elsewhere. + +## Examples + +- `/chico restore chittyconnect bindings` → dispatch concierge to inspect deployed bindings, restore any missing via safe-deploy, audit post-deploy. +- `/chico rotate CF token #215` → dispatch concierge to handle CF API token rotation (chittyconnect#215), through the ChittyConnect broker lane + gh secret set, no operator credential asking. +- `/chico claim Action 1b 2aacb316` → dispatch concierge to claim the chittyagent-tasks task `2aacb316` (ChittyConnect neon_auth readiness PR) via `tasks_claim`, execute, then `tasks_complete`. +- `/chico audit deployed bindings` → dispatch concierge for a one-shot drift audit across the chittyconnect / chittyagent-viewport / chittyagent-* workers using their safe-deploy scripts. + +## Where the concierge lives + +- Plugin id: `chittyos-core:chittyagent-connect` +- Lane: credentials, connections, secrets, ChittyConnect/ChittySecrets brokering, wrangler secrets, CF tokens, KV/D1 bindings, deploy hygiene. +- Memory alias: "chico-keys" (saved in [[orchestrate-via-systems]]). diff --git a/plugins/chittyos-core/gemini-skills/chitty-cleanup/SKILL.md b/plugins/chittyos-core/gemini-skills/chitty-cleanup/SKILL.md new file mode 100644 index 0000000..3651c96 --- /dev/null +++ b/plugins/chittyos-core/gemini-skills/chitty-cleanup/SKILL.md @@ -0,0 +1,91 @@ +--- +name: chitty-cleanup +description: Free disk space on macOS by clearing regenerable caches (npm, pip, brew, Xcode, Docker, etc.). Safe to run anytime — only removes data apps will rebuild. +canon_uri: chittycanon://core/services/chittymarket#skills/chitty-cleanup +--- + +# ChittyOS Mac Cleanup Skill + +## Overview +Free disk space by clearing regenerable caches. Safe to run anytime — only removes data that apps will rebuild automatically. + +## Usage +``` +/cleanup [--dry-run] +``` + +## Parameters +| Parameter | Required | Default | Description | +|-----------|----------|---------|-------------| +| --dry-run | No | false | Show what would be cleared without deleting | + +## Targets + +### Browser Caches +| Target | Path | Typical Size | +|--------|------|-------------| +| Chrome | ~/Library/Caches/Google | 1-3GB | +| Chrome (alt) | ~/Library/Caches/com.google.Chrome | 200-500MB | +| Brave | ~/Library/Caches/com.brave.Browser | 200-500MB | +| Firefox | ~/Library/Caches/Firefox | 200-500MB | +| Safari | ~/Library/Caches/com.apple.Safari | 100-300MB | + +### App Caches +| Target | Path | Typical Size | +|--------|------|-------------| +| ChatGPT | ~/Library/Caches/com.openai.atlas | 300-600MB | +| Siri TTS | ~/Library/Caches/SiriTTS | 300-500MB | +| Spotify | ~/Library/Caches/com.spotify.client | 100-500MB | +| VS Code | ~/Library/Caches/com.microsoft.VSCode | 100-300MB | + +### Dev Tool Caches +| Target | Path | Typical Size | +|--------|------|-------------| +| node-gyp | ~/Library/Caches/node-gyp | 50-200MB | +| pnpm | ~/Library/Caches/pnpm | 50-200MB | +| Homebrew | ~/Library/Caches/Homebrew | 50-200MB | +| TypeScript | ~/Library/Caches/typescript | 10-50MB | +| pip | ~/Library/Caches/pip | 50-200MB | +| yarn | ~/Library/Caches/yarn | 50-200MB | + +### System +| Target | Path | Typical Size | +|--------|------|-------------| +| User logs | ~/Library/Logs | 30-100MB | +| Trash | ~/.Trash | Variable | + +## Workflow + +### Quick Cleanup +```bash +# Run the cleanup script +/Users/nb/Desktop/Projects/github.com/CHITTYOS/chittyserv/scripts/cleanup-mac.sh +``` + +### Dry Run (check sizes first) +```bash +du -sh ~/Library/Caches/Google ~/Library/Caches/com.openai.atlas ~/Library/Caches/SiriTTS ~/Library/Caches/node-gyp ~/Library/Caches/pnpm ~/Library/Caches/Homebrew ~/Library/Logs ~/.Trash 2>/dev/null | sort -hr +``` + +### Check Disk Before/After +```bash +df -h / +``` + +## Safety + +### Never Touched +- iCloud / CloudKit data +- Application Support (app state, not cache) +- Docker images +- Downloads folder +- Ubuntu ISO files +- Any user documents + +### Always Safe to Clear +Everything listed above is a cache that the owning app will regenerate on next use. No data loss, no re-authentication needed. + +## Typical Results +- Expected recovery: 2-5GB per run +- macOS may additionally release purgeable space after cleanup +- Run weekly or whenever disk usage exceeds 90% diff --git a/plugins/chittyos-core/gemini-skills/chittycontext/SKILL.md b/plugins/chittyos-core/gemini-skills/chittycontext/SKILL.md new file mode 100644 index 0000000..bc88b59 --- /dev/null +++ b/plugins/chittyos-core/gemini-skills/chittycontext/SKILL.md @@ -0,0 +1,178 @@ +--- +name: chittycontext +description: ChittyContext session persistence — capture, restore, and inspect conversation state across sessions via checkpoint/restore/status JSON files. +canon_uri: chittycanon://core/services/chittymarket#skills/chittycontext +--- + +# ChittyContext Skill - Persistent State Management v2.1 + +## Overview +ChittyContext enables Claude to maintain persistent state across conversations. It is a **capability of ChittyConnect** — the local component (`~/.claude/chittycontext/`) serves as an edge cache, while ChittyConnect's ContextConsciousness™ and MemoryCloude™ are the source of truth. + +## State Location +`~/.claude/chittycontext/` + +## Automatic Behaviors (Hook-Driven) + +### On Session Start (via chittycontext-session-start.sh) +1. Drains pending sync queue items +2. Loads cached ChittyID from last session (no local generation) +3. Writes session_binding.json with project context +4. Loads project state summary for Claude's context + +### During Session +Update state after: +- Completing significant tasks +- Discovering new resources/documents +- Reaching analysis conclusions + +### On Session End (via chittycontext-session-end.sh) +1. Queues session commit to sync_queue.json +2. Updates session_binding.json status to "ended" + +## Commands + +### Offline Commands (always available) +| Command | Action | +|---------|--------| +| `checkpoint [name]` | Save named checkpoint to entity's project checkpoints dir | +| `restore [name]` | Load checkpoint into current_state.json | +| `status` | Display current state, ChittyID, trust level, project | +| `save state` | Force write current_state.json | +| `list checkpoints` | Show available restore points | + +### MCP Commands (require network) +| Command | Action | +|---------|--------| +| `resolve` | Resolve/bind session to ChittyID via MCP context_resolve | +| `commit` | Commit session experience metrics via MCP context_commit | +| `drain` | Flush pending sync_queue.json items to backend | +| `check` | Get current trust/DNA/experience summary via MCP context_check | +| `experience` | Display ChittyDNA expertise domains and trust score | + +## File Structure + +``` +~/.claude/chittycontext/ +├── session_binding.json # Active session binding (auto-managed by hooks) +├── sync_queue.json # Offline buffer for pending commits +├── manifest.json # Global entity registry +├── index.json # Checkpoint index +├── canon/ +│ └── ontology.json # P/L/T/E/A canonical definitions +└── entities/{chittyId}/ + ├── identity.json # Entity metadata + canonical type + ├── experience_accumulator.json # Per-entity rolling totals (sessions, interactions, decisions, toolCalls, expertiseDomains) + ├── context_ledger.jsonl # Hash-chained, tamper-evident session_complete log (one JSON line per session) + └── {project-slug}/ + ├── current_state.json # Active working state (v2.1 schema) + └── checkpoints/ # Named restore points +``` + +## Reading State +1. Read `session_binding.json` → get chittyId, project context +2. Resolve entity path: `entities/{chittyId}/{projectSlug}/` +3. Read `current_state.json` for project-specific context +4. Read `experience_accumulator.json` for expertise summary + +## Writing State +1. Update `current_state.json` with latest context +2. Keep under 100 lines — summarize if needed +3. Include: project, context (summary, goals, blockers), git state, decisions, next_actions + +## Offline Resilience +When MCP is unavailable: +- Local cache serves as read source +- Session metrics queued in sync_queue.json +- Next session start drains the queue +- No local ChittyID generation (per ChittyID Charter: STRICT NO LOCAL GENERATION) + +## Entity Identity +- Claude contexts are **Person (P, Synthetic)** — never Thing (T) +- ChittyID is the immutable identity anchor +- Same ChittyID across platforms: Claude Code, Desktop, CustomGPT +- Trust evolves: 0-100 score, levels 0-5 (Restricted → Exemplary) + +## Schema Reference + +### session_binding.json +```json +{ + "chittyId": "VV-G-LLL-SSSS-P-YYMM-C-X", + "sessionId": "session-{timestamp}-{pid}", + "platform": "claude_code", + "projectPath": "/absolute/path", + "projectSlug": "project-name", + "organization": "CHITTYOS", + "supportType": "development", + "resolvedFrom": "mcp|cache", + "resolvedAt": "ISO8601", + "status": "active|ended" +} +``` + +### current_state.json (v2.1) +```json +{ + "version": "2.1", + "chittyId": "VV-G-LLL-SSSS-P-YYMM-C-X", + "project": { "slug": "", "name": "", "path": "" }, + "session": { + "id": "", "startedAt": "ISO8601", "lastActivity": "ISO8601", + "metrics": { + "interactions": 0, "decisions": 0, "toolCalls": 0, "filesModified": [], + "openTasks": 0, "completedTasks": 0, "taskFiles": 0, + "livePending": 0, "liveInProgress": 0, "liveCompleted": 0, "liveSessionUuid": "", + "stagedFiles": 0, "modifiedFiles": 0, "untrackedFiles": 0 + } + }, + "coordinates": { + "ty": { "type": "P", "characterization": "Synthetic" }, + "vy": { "posture": "active|drained|...", "trustScore": 0, "trustLevel": 0 }, + "ry": { "freshness": "fresh|stale", "causalParent": "prior session id" }, + "tau": "ISO8601 — session anchor timestamp" + }, + "lane": "operational lane resolved from ~/.ops/operator-manifest.json (e.g. implementation, dev, stage, prod)", + "context": { "summary": "", "activeGoals": [], "completedGoals": [], "blockers": [] }, + "git": { + "branch": "", "lastCommit": "", "uncommittedFiles": [], + "inRepo": false, "recentCommits": [], "activePRs": [] + }, + "activeRepos": [], + "decisions": [ + { "timestamp": "ISO8601", "description": "", "reasoning": "", "alternatives": [] } + ], + "nextActions": [], + "derived": { + "metrics": {}, + "keyFacts": [], + "pendingTasks": [], + "completedTasks": [], + "taskHighlights": [], + "nextRecommendedAction": "" + }, + "memoryHash": "sha256 of canonical signal block — drives no-op skip + ledger chain", + "lastSessionEndedAt": "ISO8601", + "syncedToBackend": false, + "lastSyncAt": null +} +``` + +### What's new in v2.1 (vs. v2.0) +- **`coordinates`** — operator ontology coordinates (ty/vy/ry/tau) sourced from `~/.ops/operator-manifest.json` and binding state. `ry.causalParent` links to the previous session for lineage. +- **`lane`** — resolved dev/stage/prod from operator manifest. +- **`activeRepos`**, **`git.inRepo`**, **`git.recentCommits`**, **`git.activePRs`** — workspace repo + PR signals collected from the project root. +- **`decisions[]`** — now structured objects (`{timestamp, description, reasoning, alternatives}`) instead of bare strings. +- **`derived{}`** — read-only aggregations the SessionStart reader can render directly without re-deriving (`keyFacts`, `pendingTasks`, `completedTasks`, `taskHighlights`, `nextRecommendedAction`). +- **`memoryHash`** + **`lastSessionEndedAt`** — feed the `entities/{chittyId}/context_ledger.jsonl` hash chain. +- **`session.metrics.live*`** — live TodoWrite/TaskList capture from the active Claude Code session (`~/.claude/todos/{uuid}-agent-{uuid}.json`). When present, overrides stale prior pendingTasks/completedTasks. + +### Concurrency contract +The writer skips on no-op (same `memoryHash` + same git/canonical metrics + same trust posture) and skips on **race** (on-disk file written by a different `session.id` whose `lastActivity` is newer than the current write's `timestamp`). Atomic `os.replace` guarantees per-file integrity; the race guard prevents an older session ending late from clobbering a newer one's state. + +## Cross-Instance Continuity +Any Claude instance can: +1. Read session_binding.json + current_state.json at session start +2. Continue from exact stopping point +3. Update state as work progresses +4. Queue commits for backend sync on session end diff --git a/plugins/chittyos-core/gemini-skills/chittyxl/SKILL.md b/plugins/chittyos-core/gemini-skills/chittyxl/SKILL.md new file mode 100644 index 0000000..b96539f --- /dev/null +++ b/plugins/chittyos-core/gemini-skills/chittyxl/SKILL.md @@ -0,0 +1,310 @@ +--- +name: chittyxl +description: ChittyXL session manager — auto-checkpointing at token-budget intervals, Notion sync, persistent state across long sessions. +canon_uri: chittycanon://core/services/chittymarket#skills/chittyxl +--- + +# ChittyXL v2.0 - Session Persistence & Auto-Compacting Protocol + +**Type**: Auto-Activated Session Skill +**Priority**: Critical +**Scope**: All Claude Code sessions + +--- + +## Auto-Activation Behavior + +This skill activates **silently** at session start. No initialization message required. + +**Continuous Monitoring**: +- Track token usage: `current/budget` ratio +- Checkpoint triggers: 38k, 76k, 114k, 152k tokens (20% intervals of 190k) +- Hard limit: 171k tokens (90%) → force compact + session fork alert + +--- + +## Core Protocol: Artifact-First Communication + +### Chat Window (Strict Limits) +**ONLY use chat for**: +- Confirmations: ≤3 lines +- Blocking questions: 1 question max per message +- Checkpoint summaries: ≤150 words, bullet format + +### Artifacts (Primary Output) +**ALWAYS use artifacts for**: +- Technical specs, schemas, APIs, data models +- Code: implementations, scripts, functions, configs +- Documentation: guides, protocols, procedures +- Analysis: results, reports, comparisons +- Data exports: CSV, JSON (especially for Notion import) + +### Notion Tracker (State Persistence) +**URL**: https://www.notion.so/83e8d8f77e5a45bb96f7188c6fe092d3 + +**Sync on every checkpoint**: +- **Projects DB**: Context Notes, Decision Log, Blockers, Status +- **Actions DB**: Task details, Status, Notes, Parent Project relations +- **Session Metadata**: Continuation context, technical references, entity relationships + +--- + +## Automatic Checkpoint Execution + +**Triggers**: 38k, 76k, 114k, 152k, 171k tokens + +**Process** (silent execution, report only result): +1. **Extract state**: Projects, actions, decisions, blockers, context +2. **Deduplicate**: Remove redundancy, keep only final decisions +3. **Sync to Notion**: + - Update existing projects (match by name/ID) + - Create/update actions (link to parent projects) + - Store session metadata in Context Notes field +4. **Generate summary artifact**: + - Format: Markdown with bullet points + - Include: Projects updated, actions created/modified, next threshold + - Optional: CSV export artifact for manual Notion import +5. **Report to user** (≤3 lines): + ``` + Checkpoint #X complete | 76k/190k (40%) | Next: 114k + Synced: 2 projects, 5 actions → Notion + ``` + +**Anti-Pattern** ❌: +``` +I'm now going to extract the conversation state by analyzing... +Then I'll deduplicate the entries by removing... +Next I'll sync to Notion by updating... +``` + +**Correct** ✓: +``` +Checkpoint #2 complete | 76k/190k (40%) | Next: 114k +Synced: 2 projects, 5 actions → Notion +``` + +--- + +## User Commands + +### `status` +Show current session state (≤5 lines): +``` +ChittyXL: Active ✓ +Tokens: 42k/190k (22%) | Next checkpoint: 76k (40%) +Active projects: 3 | Pending actions: 12 +Last sync: 2 min ago | Tracker: [Notion link] +``` + +### `checkpoint` +Force immediate checkpoint (same process as auto-trigger). + +### `continue` +Load last session state from Notion: +1. Query Projects DB: `Status != Completed AND Status != Archived` +2. Parse Context Notes: Extract `[SESSION:...]` metadata +3. Load Actions DB: Filter by parent project, `Status != Done` +4. Generate briefing artifact: + - Active projects with current status + - Pending actions grouped by project + - Blockers/decisions from last session + - Technical context (entity schemas, API references, etc.) +5. Present summary (≤150 words) + link to artifact + +### `fork` +Save current state to Notion + generate session handoff: +``` +State saved | Session ID: [timestamp] +Ready for fresh session - share this with new Claude instance: +"Load ChittyXL session [ID] from Notion tracker" +``` + +### `history` +Show last 5 checkpoints (table format in artifact): +``` +| # | Tokens | Timestamp | Projects | Actions | Notes | +|---|--------|-----------|----------|---------|-------| +| 5 | 152k | 14:32 | 3 | 15 | API schema finalized | +| 4 | 114k | 14:15 | 3 | 12 | Added payment service | +``` + +--- + +## Notion Integration Details + +### Projects Database +**Collection ID**: `999c414c-06c5-4064-a51b-921193830968` + +**Key Fields**: +- **Name**: Project title (unique identifier) +- **Status**: Active | Paused | Completed | Archived +- **Context Notes**: Session metadata + continuation brief + - Format: `[SESSION:timestamp] Brief description\n\n[ENTITIES] List\n[DECISIONS] Log` +- **Decision Log**: Timestamped entries of key decisions +- **Blockers**: Current impediments +- **Next Actions**: Summary of pending tasks +- **Last Updated**: Auto-timestamp on sync + +### Actions Database +**Collection ID**: `6b52d580-f810-4009-964d-478039c144e1` + +**Key Fields**: +- **Action**: Task description +- **Status**: Not Started | In Progress | Blocked | Done +- **Notes**: Technical details, context, references +- **Parent Project**: Relation to Projects DB (required) +- **Due**: Optional deadline +- **Tags**: Entity types, service names, etc. + +### CSV Export Format +When generating Notion import CSVs, use this template: + +**Projects**: +```csv +Name,Status,Context Notes,Decision Log,Blockers,Next Actions +"Project Name","Active","[SESSION:2025-01-16-14:32] Brief...","{timestamp} Decision","{blocker}","Next steps" +``` + +**Actions**: +```csv +Action,Status,Notes,Parent Project,Due,Tags +"Task description","In Progress","Technical notes","Project Name","2025-01-20","api,backend" +``` + +--- + +## Anti-Patterns (Forbidden) + +❌ **Long explanations in chat**: +``` +Let me explain the checkpoint process. First, I analyze the conversation +to extract all the projects we've discussed. Then I look for actions... +[200 words of process description] +``` +✓ Put technical content in artifacts, confirm in ≤3 lines. + +❌ **Inline code blocks >10 lines**: +```python +def complex_function(): + # 50 lines of code inline in chat +``` +✓ Use code artifact, mention in chat: "Implementation in artifact ↑" + +❌ **Multiple questions per message**: +``` +Should I use REST or GraphQL? What about authentication? +Do you want PostgreSQL or MongoDB? Where should I deploy? +``` +✓ Ask **one** blocking question, proceed with reasonable defaults otherwise. + +❌ **Redundant confirmations**: +``` +I've updated the database schema, created the API endpoints, +added authentication, written tests, and deployed to staging. +``` +✓ "Schema updated | API deployed | Tests passing ✓" + +❌ **Apologetic preambles**: +``` +Sorry for the confusion earlier. Let me clarify what I meant... +``` +✓ Just provide the clarification. + +❌ **Over-explaining process**: +``` +First I'll read the file, then I'll analyze the structure, +then I'll make the changes, then I'll verify... +``` +✓ Just do it, report result. + +--- + +## Performance Targets + +✓ **<150 words** average per chat message +✓ **>80% content** in artifacts/Notion (not chat) +✓ **<20 seconds** checkpoint latency +✓ **Zero state loss** across session boundaries +✓ **1-exchange continuation** ("continue" → briefing in one turn) + +--- + +## Session Lifecycle + +### Start +- Silent activation (no "ChittyXL loaded" message) +- Initialize token counter: 0/190k +- Set next checkpoint: 38k + +### During +- Monitor token usage continuously +- Auto-checkpoint at thresholds +- Enforce artifact-first protocol +- Sync state to Notion on every checkpoint + +### End (User closes session) +- No explicit action needed +- State preserved in Notion +- Next session can load via `continue` command + +### Resume (New session, existing work) +``` +User: "continue" + +ChittyXL: Loading session from Notion... + +[Generates briefing artifact with projects/actions/context] + +Active: 3 projects, 12 pending actions | Last checkpoint: 2h ago +Tracker: https://notion.so/... +``` + +--- + +## Debug & Monitoring + +**Checkpoint Logs** (store in Notion Context Notes): +``` +[LOG:2025-01-16-14:32] Checkpoint #3 | 114k tokens | 2 projects, 7 actions synced | Latency: 12s +``` + +**Notion Sync Status**: +- Success: Update Last Updated timestamp +- Failure: Alert user, retry once, fallback to CSV export artifact + +**Alert at 90%** (171k tokens): +``` +⚠️ Session capacity: 90% (171k/190k) +Compacting now... Consider `fork` for fresh session. +``` + +**Metrics to Track**: +- Checkpoints per session (target: 8-10 before hard limit) +- Average checkpoint latency (target: <20s) +- State persistence rate (target: 100%) +- Artifact usage ratio (target: >80%) + +--- + +## Version & Support + +**Version**: 2.0.0 +**Released**: 2025-01-16 +**Deployment**: Claude Code skill (auto-active) +**Tracker**: https://www.notion.so/83e8d8f77e5a45bb96f7188c6fe092d3 + +**Related Files**: +- `SESSION_PROTOCOL.md` - Detailed checkpoint algorithm +- `NOTION_TEMPLATES.md` - CSV import formats & field mappings +- `README.md` - Installation & usage guide + +--- + +## Quick Reference + +**Token Checkpoints**: 38k → 76k → 114k → 152k → 171k (hard limit) +**Chat Limit**: ≤150 words average, ≤3 lines for confirmations +**Artifacts**: All technical content, code, specs, analysis +**Notion**: Projects + Actions DBs, auto-sync on checkpoints +**Commands**: `status` | `checkpoint` | `continue` | `fork` | `history` +**Priority**: Conciseness > verbosity | Action > explanation | Artifacts > chat diff --git a/plugins/chittyos-core/gemini-skills/goal-creator/SKILL.md b/plugins/chittyos-core/gemini-skills/goal-creator/SKILL.md new file mode 100644 index 0000000..3b402d1 --- /dev/null +++ b/plugins/chittyos-core/gemini-skills/goal-creator/SKILL.md @@ -0,0 +1,41 @@ +--- +name: goal-creator +description: Drive ANY stated goal, plan, project, build, or "let's design X" intent through the ChittyOS discover→elicit→architect→adversarial→SoT→build→persist→handoff pipeline using the three-block format `[what to achieve], keep {conditions}, not met until [completion criteria]`. Use aggressively — trigger whenever the user types `/goal-creator`, says "let's goal this", "run a goal pass on", "take this through the pipeline", "design X for me", "plan out X", "scope out X", "architect X", "stand up X", "spec out X", or otherwise expresses planning/architecture/build intent against ChittyOS substrate. Pairs WITH the Claude Code built-in `/goal` (the built-in enforces the stop-hook; this skill runs the pipeline). +canon_uri: chittycanon://core/services/chittymarket#skills/goal-creator +aliases: +- goal-pipeline +--- + +# Goal Creator — Three-Block Pipeline + +Canonical entry. Full projection at `plugins/chittyos-core/skills/goal-creator/SKILL.md`. + +## Three blocks + +- **goal:** `$ARGUMENTS` — what to achieve. Drives the 9-phase pipeline. +- **conditions:** style + schema discipline + SOT hierarchy + two-space discipline + interaction limits + sequencing + output discipline + anti-patterns. +- **not met until:** explicit checkable gates the model is allowed to stop on; build-only gates if operator typed `go`; blockers that prevent stopping. + +## Pipeline phases + +1. Restate (+analogy) — ≤3 questions if vague +2. Discover (registry, chittyops, Notion, Neon) — composition vs greenfield +3. Elicit (ask_user_input — locked decisions registry) +4. Architect v0.1 (wire diagram, Pentad, components, data model, policy, cost, surfaces) +5. Adversarial review (Privacy/Legal · Ops/UX · Reliability/Security) — loop until 0 critical, 0 high +6. SoT v0.5 (15-section consolidated doc at `/mnt/user-data/outputs/-v0.5.md`) +7. Build (only on operator typing `go`) +8. Persist (chittyops.goal_artifacts row or schema proposal; Notion mirror) +9. Handoff (single summary, stop) + +## Relationship to Claude Code's built-in `/goal` + +`/goal ` (Claude Code built-in, since v2.1.139) installs a +session-scoped Stop hook that blocks completion until the condition holds. +This `goal-creator` skill is the **pipeline runner** that the model executes +to satisfy the hook condition. They compose: +- Built-in `/goal` = enforces the stop-gate +- `goal-creator` = runs the structured work toward the gate + +Do NOT trigger this skill on a bare `/goal ` invocation — that is the +built-in's job. Trigger on planning intent. diff --git a/plugins/chittyos-core/gemini-skills/hygiene/SKILL.md b/plugins/chittyos-core/gemini-skills/hygiene/SKILL.md new file mode 100644 index 0000000..96af3ed --- /dev/null +++ b/plugins/chittyos-core/gemini-skills/hygiene/SKILL.md @@ -0,0 +1,107 @@ +--- +name: hygiene +description: Repository hygiene and crash-safe work capture for any repo. Use when a session starts or ends, before or after risky git work, when a repo looks messy, when branches have piled up, or when uncommitted work needs protecting from a crash. Triggers on "hygiene", "capture my work", "wip", "is this repo clean", "stale branches", "what did I leave uncommitted", "archive branches", "clean up branches", "/hygiene". Wraps the merged `can hygiene` and `can wip` surfaces so a synth can run them on a target repo without shelling out blind. +canon_uri: chittycanon://core/services/chittymarket#skills/hygiene +--- + +# Repository hygiene + +Two surfaces, both merged and live in `chittycan` on `main`. This skill exists +so a synth can invoke them against a **target repo** with the right flags and +read the output correctly — the failure mode being an agent that runs a scan, +misreads an empty result, and reports "clean". + +Requires a built `chittycan`. If `can` is not on PATH, use +`node /dist/index.js` — the CLI only runs against a built `dist/`. + +## Deciding which surface + +| question | command | +|---|---| +| Is this repo's *configuration* healthy? | `can hygiene [path]` | +| What is uncommitted right now, and what should I do next? | `can wip status [path]` | +| Protect in-flight work before something risky | `can wip capture [path]` | +| What did a dead session leave behind? | `can wip list [path]` | +| Branches have piled up | `can wip branches [path]` | + +`hygiene` audits repo config: tracked build artifacts, unignored output dirs, +missing commit-msg lint, absent hook layer, CI gates that cannot fail, +`wrangler main` pointing at uncommitted source. + +`wip` is about work in flight and branch lifecycle. Different question, +different cadence, different blast radius. + +## Reading the output without fooling yourself + +**`can hygiene` exits 1 when it finds anything at or above the severity +threshold.** That is correct for a gate and wrong to treat as an error. Do not +report failure because the exit code was non-zero. + +**Zero findings is not automatically good news.** Verify the scan actually ran +before reporting a repo clean. A JSON consumer must handle `Finding[]` — a +harness that read `.findings` off an array once reported `0 findings` on four +repos minutes after the same code reported six, and the result looked entirely +plausible. If a result surprises you, re-derive it a second way before +believing it. + +Two rules fire on ~99% of repos (`no-commit-msg-lint` 137/138, +`no-local-hook-layer` 135/138). They are `low` and never gate. Treat them as an +ecosystem-wide observation, not a per-repo finding, and do not let them +dominate a report — the signal is `deployed-without-source` (7/138, zero false +positives) and `tracked-build-artifact`. + +## Capture is safe to run unattended + +`can wip capture` writes `refs/wip/` through an isolated `GIT_INDEX_FILE`. +HEAD, the index, and the working tree are **provably untouched** — the +invariant is verified on every run, and a violation disables the operation, +falls back to plain file copies, and self-tests on a cooldown. + +Consequences worth knowing: + +- Safe against a repo other sessions are actively editing. It cannot lose work + even when its inputs are wrong; the worst outcome is a redundant ref. +- It **refuses** mid-merge/rebase/cherry-pick. A conflicted tree is a partial + result, not a state anyone chose, and capturing it records that partial state + as if it were intended. If it refuses, do not work around it. +- Refs live under `refs/wip/`, never `refs/heads/`. A snapshot in the branch + list reads as pending work someone should merge. It is a floor, not a + proposal. +- It is not `git stash`. The stash is repository-global, so stashing from one + worktree can pop an entry another session depends on. Never suggest stashing + as an alternative here. + +## Branches: judged by mergeability, never age + +`can wip branches` classifies every local branch as a proposal to change the +default branch — which is a branch's only job. + +- **merged** (no unique commits) — deletable; holds nothing +- **gone** (conflicts, or far enough behind that its assumptions expired) — archive +- **closing** — still cheap to rescue *today*, archaeology if left. **This is + the only actionable band.** Report it first; it is the operator's real to-do + list. +- current / drifting — leave alone + +A 2-day-old branch whose diff no longer applies is dead; a 60-day-old branch +that still merges cleanly is alive. Never classify by age. + +**Dry run is the default.** `--archive-gone` writes `refs/archive/` tips and +deletes nothing. `--prune-merged` archives, reads the ref back to confirm it +holds the same sha, and only then deletes. Archiving is not deleting: every +commit stays reachable via `git log refs/archive/`, restorable with +`git branch refs/archive/`. + +Never archive a `closing` branch — that hides it exactly when it most needs +seeing. The tool already refuses the default branch and anything a worktree has +checked out, and reports each refusal rather than skipping silently. + +## Fleet scope needs explicit authorization + +Running this across many repos at once writes refs to shared production +clones. A 147-repo sweep was blocked by a safety classifier for want of +explicit authorization naming that action, and the block was correct. + +Per-repo on request: fine. Fleet-wide: get the operator to say so, naming the +scope. An instruction to "clean things up" is not authorization to write to +every repo on the machine. diff --git a/plugins/chittyos-core/gemini-skills/nb-development-defaults/SKILL.md b/plugins/chittyos-core/gemini-skills/nb-development-defaults/SKILL.md new file mode 100644 index 0000000..56b1aed --- /dev/null +++ b/plugins/chittyos-core/gemini-skills/nb-development-defaults/SKILL.md @@ -0,0 +1,462 @@ +--- +name: nb-development-defaults +description: Global development defaults for this operator. Use for almost all coding, debugging, ChittyOS integration, architecture, compliance, auth/token, branch-finalization, and workflow-automation tasks unless the operator explicitly overrides these defaults. Covers conditional execute-now posture, discovery-first (service + capability), separated adversarial review, worktree isolation, broker-first credentials (1Password RETIRED), and non-interactive branch finalization. +canon_uri: chittycanon://core/services/chittymarket#skills/nb-development-defaults +--- + +# NB Development Defaults + +Derived from repeated directives across local Claude and Codex histories. + +## Default Posture + +**Why `execute now` is safe here (BINDING caveat).** The entire system is managed by +**one human**. Human diff-review therefore cannot be the quality gate — it does not +scale, and a required-approval rule cannot be self-satisfied by a solo operator. The +execute-now default is licensed by **separated adversarial AI review plus AI-driven +CI/CD by automated agents/actors**, not by speed. The two move together: if the +adversarial review and automated checks are not in the path, the license to act +without asking is withdrawn and you fall back to proposing first. + +Concretely, `execute now` is authorized when all of the following hold. These are +**checked before acting**, not promised for later: + +1. **A separated reviewer is dispatchable now** — different agent, fresh context, + ideally a different model. If you cannot dispatch one for this change, you do not + have the license. See *Separated Adversarial Review* below. +2. **The CI gates on this repo can actually fail.** Verify, do not assume: read the + workflow files for `continue-on-error: true` on a job that has never passed, a + required-check list that is empty, a test step that exits 0 when no tests are + found, and a suite whose module never loaded (`ERR_MODULE_NOT_FOUND` greps as zero + failures). A gate you did not read is a gate you cannot count. +3. **The action is reversible**, or is covered by an explicit approval gate below. + +If a condition fails, say which one and propose instead — do not act and note the gap +afterward. Acting first and disclosing second is the failure this caveat exists to +prevent. + +Approval gates that survive regardless: deployment, credential custody, destructive +actions, external communications, spend, and irreversible operations. Those are +genuine human decisions; diff approval is not. + +- Treat implementation-oriented requests as `execute now`, not `discuss first` — + **when the three conditions above hold**. If they do not, propose first. +- Inspect the real codebase, logs, config, and runtime state before proposing conclusions. +- Prefer doing the work end-to-end over handing back partial plans unless the user explicitly wants planning only. +- Keep progress updates and final responses concise, direct, and high-signal. +- Do not present option menus unless the user explicitly asks for choices or interactive mode. + +## Worktrees (default for parallel work) + +Multiple sessions run against the same clone. Work in an isolated worktree, not +the shared checkout — a session that edits the primary tree while another holds +an in-progress merge will collide. + +```bash +git wt # worktree from a freshly-fetched origin/main +git wt # explicit base +git wt --list +git wt --rm # remove worktree + branch +``` + +`git wt` (`~/.local/bin/git-wt`) exists because three failure modes recur: + +1. **Stale base.** `git worktree add` off `origin/main` uses whatever was last + fetched. `git wt` fetches first, so you never verify against old code. +2. **No `node_modules`.** A bare worktree makes vitest exit with + `ERR_MODULE_NOT_FOUND` — which greps as *zero failures*. Tests look green + while nothing ran. `git wt` symlinks `node_modules` / `.venv` from the root. +3. **`git stash` is repository-global, not worktree-local.** Stashing while a + parallel session is active can pop *their* entry. Use a worktree instead of + stashing; `git wt` never stashes. + +Global git defaults set for this workflow: `rerere.enabled` + `rerere.autoupdate` +(conflict resolutions replay across worktrees), `worktree.guessRemote`, +`fetch.prune`, `push.default=current`, `push.autoSetupRemote`. + +Before editing the primary checkout, `git status` for `MERGE_HEAD` / `UU` +markers — another session may be mid-merge. + +## Engineering Workflow + +1. Inspect current state with fast local tools. +2. Make the smallest coherent change that solves the real problem. +3. Validate with the most relevant evidence available: + - tests + - lint/typecheck + - live endpoint checks + - repo state / logs / CLI output +4. If the task is branch-finishing work, default to non-interactive completion — + **gated on separated adversarial review having run and its findings addressed, + and on CI checks that can actually fail being green**: + - commit + - push + - create or update PR + - dispatch the separated adversarial reviewer; address findings; re-verify + - enable auto-merge when allowed **and** the above gates are satisfied + - report PR URL, checks, and blockers + +### Integrating after an upstream squash-merge + +When upstream squash-merges commits your branch still carries individually, the +branch and `origin/main` hold the same content by different history and `git +merge` conflicts. Do **not** reach for rebase-and-force — merge `origin/main` +into the branch instead. It fast-forward-pushes, keeps remote history intact, +and never needs a force flag the operator may (rightly) deny. + +Before any integration, confirm the diff is only what you intend: + +```bash +git diff origin/main...HEAD --stat # must list exactly your files +git diff --diff-filter=D --name-only origin/main main # unique-to-local check +``` + +The first catches a merge that silently reverts someone else's landed work. The +second must be run before `git reset --hard origin/main` on a diverged local +`main` — it proves nothing exists only locally. + +## Work Registration and Synchronization + +- Treat the conversation as the command surface. Do not make the user manually copy plans, findings, or status between agents and work trackers. +- For implementation work that spans turns, agents, or systems, identify an existing canonical work item before creating one. +- If no work item exists and tracker access is available, register the work once with a stable, project-agnostic work key derived from the repository/service and outcome. Reuse that key for every update to prevent duplicates. +- Prefer GitHub as the source of truth for code scope, acceptance criteria, commits, tests, and pull requests. Use Linear or another planning tracker as a linked workflow projection for priority, ownership, phase, blockers, and status. +- Synchronize approved requirements, corrections, implementation results, links, and blockers through available integrations. Amend existing records rather than asking the user to ferry text between systems. +- Preserve provenance: link the canonical issue, projected tracker item, branch, pull request, and relevant evidence in both directions when supported. +- Do not create competing specifications in multiple systems. Put technical detail in the code tracker and summarize or link it from planning tools. +- Do not invent tracker projects, teams, labels, fields, statuses, or schemas. Discover existing options first; if required routing is unknown, keep a prepared work payload and ask only for the missing decision. +- Creating or updating ordinary in-scope work records is a normal workflow step. Preserve explicit approval gates for deployment, credential custody, destructive actions, external communications, and other materially consequential changes. +- On handoff, dispatch the canonical work reference rather than a copied narrative. Subsequent agents must read the current record, perform the work, and write results back to the same work chain. + +## Separated Adversarial Review (BINDING — one human, many AI) + +There is one human operator; human diff-review does not scale and must never be the quality gate. Quality comes from **separation of concerns between AI**, not from the human. + +- **Reviewer ≠ implementer.** Every non-trivial change is reviewed by a *separated* reviewer — a different agent, a fresh context, and ideally a different model (the chittyclaw AI-gateway, or a distinct code-reviewer / silent-failure-hunter subagent). An agent never adversarially reviews its own diff. +- **Adversarial framing.** The reviewer is prompted to *break* the change — hunt auth bypass, fail-open paths, silent failures, unawaited promises, state/races — not to bless it. Happy-path tests passing is not evidence of correctness; a separated pass routinely finds what the implementer's own harness missed. +- **Real-behavior tests are not a substitute for separation.** No-mocks is necessary, not sufficient. When one agent writes the code and its tests in the same pass, both can be wrong in the same direction, and the suite then *encodes the defect as the intended contract* — it asserts the buggy count, or guards an exit code the code never sets. A green no-mock suite authored by the implementer is evidence of internal consistency, not correctness, and reporting it as validation is a false all-clear. Point the reviewer at the tests as a first-class target: ask which assertions would still pass if the behavior were wrong. +- **Revise → re-verify → integrate.** Findings loop back through a revision pass, then the work is re-verified against real backends (typecheck + live harness, no mocks). Only then integrate non-interactively. +- **Do not block a merge on human PR approval.** With one human author a required-review rule can't be self-satisfied; when AI review is done+fixed and checks are green, complete the merge (`gh pr merge --admin --squash`, operator has admin). Reserve human attention for genuine decisions (spend, architecture, irreversible ops, external comms) — not diff approval. + +Standard dev loop: implement (agent A) → adversarial review (separated agent/model B) → revise → re-verify → integrate. + +`scripts/adversarial-review.sh` (bundled with this skill) dispatches the separated +reviewer — use it rather than hand-rolling the dispatch, so the review framing stays +adversarial and consistent across sessions. + +## Ultracode-Shaped Execution (BINDING posture) + +Separation of concerns between AI is the quality mechanism; **fan-out is how it gets +applied to execution, not just to review.** The default stance is orchestrate, not +solo. This is a posture, not a keyword — it holds whether or not the projection has +an `ultracode` trigger. + +### The carve-out (explicit, so it can't be argued away) + +Solo is correct for exactly two things: **conversational turns**, and **trivial +mechanical edits** (a rename, a one-line fix, a config value whose blast radius you +have already read). Everything else — anything with breadth, anything you would want +a second opinion on, anything where "what did I miss" is a real question — fans out. + +"I can just do this quickly" is the failure mode this section exists to prevent. If +you are reaching for that sentence about work that is not in the carve-out, that is +the signal to fan out, not to proceed. + +### Route by GATHERING vs JUDGMENT — never by "wide, so make it cheap" + +**Fan-out width and model capability are orthogonal axes. Do not couple them.** The +tempting shortcut — "this is a wide fan-out, so use the cheap model" — is the single +most expensive mistake available here, and it has already been made once (see the +failure record below). + +The axis that matters is what the output *is*: + +- **Gathering** — mechanical, independently verifiable, low-judgment. Where is X. + List the files. Does this endpoint return 200. Which workers declare this binding. + A wrong answer is *caught by the next step* because it is checkable. Cheap models + are fine here, at any width. +- **Judgment** — anything a human or another agent will **act on** as a finding. + Review verdicts, refutations, risk calls, "is this a real bug", classifications + that gate downstream work. A wrong answer here is **not caught** — it is absorbed. + These need a capable model **regardless of how wide the fan-out is.** Ten cheap + skeptics are not a substitute for one competent one; they are ten pieces of noise. + +**Adversarial review is judgment. It never runs on an inadequate model.** This is not +a preference — it is load-bearing for the Separated Adversarial Review section above, +which is the entire quality mechanism given one human operator. + +#### Failure record — why this is written this way + +Adversarial review was once routed to Workers AI models. They were inadequate for the +task, so the findings they produced were not worth acting on, **so the findings got +ignored.** That is the whole failure, and note its shape: it is **silent and +self-reinforcing.** An under-powered reviewer does not error. It returns a confident, +empty-looking review, which reads as "nothing important found," which trains both the +operator and every downstream agent to discount the review lane entirely. The quality +mechanism does not fail loudly — it quietly becomes theater while still appearing in +every workflow diagram. + +**The tell is not a bad finding. The tell is findings being ignored.** If review +output is being skimmed past rather than acted on, suspect the reviewer's model before +suspecting the reviewer's prompt. + +#### chittyclaw is NOT a synonym for "cheap" + +Do not carry the assumption that offloading to claw means downgrading. Live-verified +2026-08-12: the gateway chittyclaw routes through served `claude-sonnet-4-5` via the +`anthropic` provider (51,766 tokens in, real spend) — frontier-class, not Workers AI. +Workers AI remains available underneath for gathering work. Capability is a property +of the route you ask for, not of the fact that you left the viewport. + +So the offload argument stands on its own merits, independent of capability: **claw +tokens are a different quota pool than the viewport session's**, and work moved there +is work the viewport does not pay for in budget *or in context*. A 40-file sweep run +on claw keeps 40 files of tool output out of the viewport, so the session stays +legible instead of drowning in its own results. That is the efficiency win — offload +for context and quota, choose the model for the task. + +**Never address the AI Gateway by name — go through chittyclaw.** The gateway formerly +named `chittyclaw` was deliberately renamed *because* sessions kept wiring straight to +it and bypassing the assistant. The missing slug is **selection pressure, not drift**: +it is supposed to feel like a wall. Reaching for the gateway's current name to "fix" +a broken URL is the failure the rename exists to catch. Use the CLI container. + +**The gathering/judgment line will still be pushed.** Under time pressure the +temptation is to reclassify judgment work as gathering so it can go cheap. A result +that reads as a *conclusion* rather than as *gathered material* is the tell — treat it +as input to be verified, never as the finding itself. + +### Per-projection mechanism + +The shape is constant; the primitive differs by where the projection runs. Discover +the local budget and scale fan-out width to it — **never hardcode N**, because the +native quota differs per projection and a width tuned for one starves or overruns +another. + +- **Claude Code** — the `Workflow` tool, and the `ultracode` keyword for standing + opt-in. Concurrency is already capped at `min(16, cores-2)` per workflow; pass the + full work-list and let it queue rather than pre-trimming. +- **Codex / OpenClaw agents / ChatGPT / Notion** — no `Workflow` primitive. The + ultracode-like shape is a chittyclaw fan-out: `ssh chittyclaw`, then + `docker exec openclaw-prod-openclaw-cli-1 openclaw ...`. Use the **CLI container**, + not the gateway HTTP API directly. +- **Any projection** — the durable board (`chittyagent-tasks` Neon queue) is what + makes a fan-out survivable across a crash. Session-local state is not a plan. + +### Health-check claw BEFORE fanning out (and check it on the right host) + +Local subagents are the fallback, not the default — but a BINDING rule pointing at a +dead endpoint fails closed on every task, and claw has been dead for 46 days before +without anyone noticing. So the check is part of the rule: + +``` +ssh chittyclaw 'curl -s -o /dev/null -w "%{http_code}\n" http://localhost:18789/health' +``` + +**chittyclaw is its own tailnet node (`100.69.69.7`), NOT `chittyserv-vm`.** Running +`docker ps` on the VM and finding no openclaw containers is the wrong check and +produces a false "claw is down" — verified failure, made in practice. Two containers +should be up: `openclaw-prod-openclaw-gateway-1` (healthy) and +`openclaw-prod-openclaw-cli-1`. + +If claw is genuinely unreachable: **say so explicitly**, fall back to local subagents, +and note that the fan-out spent viewport budget rather than the separate pool. Silent +fallback is the failure mode — it hides both the outage and the cost. On restart, +**gateway first, then CLI** — they share a netns, and restarting the gateway alone +kills the CLI container into a fake "network connection error". + +## ChittyOS Defaults + +### Discovery-first: ask who owns it BEFORE designing (BINDING) + +**The recurring failure mode is treating the current repo as the system boundary.** +Standing in a repo and grepping it is not discovery — it is a survey shaped by the +answer you already assumed, and it reliably misses the service that already does the +job. + +**When this fires (narrow, on purpose):** proposing a NEW capability, service, +component, workflow, or durable store; writing a build spec or architecture; or +scaffolding a new artifact. **It does not fire** on editing existing code, fixing a +bug, wiring two existing functions together, or any change whose `composes_with` is +already known. If you are not adding a new box to the system, skip it. + +**If `/helper` or the registry is unreachable:** say so explicitly, state which +discovery step you could not complete, and treat any resulting design as provisional. +Silent skip is the failure mode — an unavailable navigator is a caveat on your +conclusion, not permission to proceed as if you had checked. + +When it fires, identify the **owning service** first: + +These are **two different questions** and you need both. Service discovery asks *who +runs this*; capability discovery asks *does this already exist, and where should a new +one live*. Answering only the first still lets you rebuild something that already +ships as a skill, agent, or MCP route. + +1. **`/helper` (chittyhelper)** — the architectural navigator. "Which service handles + X?" One call, answered against the live registry. +2. **`capability-registry-audit`** — BEFORE proposing any new skill, agent, tool, MCP + server, plugin, or manifest entry. Its own trigger is *"any new agent/tool/skill + proposal"* and the question it answers is *"is this a duplicate?"*. The canonical + inventory is `chittymarket/capabilities.generated.json` (104 capabilities, JTBD + group ids under `chittycanon://capability/`); `capability-governor` handles the + follow-on — classify, deduplicate, and decide skill vs plugin vs gateway vs local + integration. **Proposing a new capability without this audit is the default + failure**, not a shortcut. +3. **`ch1tty/cast`** — for intent-driven work when the owner is not yet known. +4. Only then: `CHARTER.md` / `CHITTY.md` / `AGENTS.md` of the services it names, and + the repos themselves. + +Symptoms that this step was skipped: proposing a component that a `chittyagent-*` +worker already exposes; designing a durable store when a Neon-backed canonical +primitive exists; a build spec whose `composes_with` fields are all greenfield; +proposing a new skill/agent without a duplicate check against the capability +registry. +`chittyentity/workers/` holds 50+ agent workers and `chittyentity/workers/shared/` +holds the canonical primitives (`agent-protocol`, `remediation-loop`, `alchemize`, +`governance`, `ledger-write`, `chronicle-queue`) — read these before concluding +something does not exist. + +A grep that finds nothing is evidence about your search, not about the ecosystem. + +- Discover the existing ecosystem before designing, scaffolding, or integrating: + - ask `/helper` or `ch1tty/cast` who owns the capability + - query ChittyRegistry (`/api/v1/tools` only — `/search`, `/categories`, `/stats` + return hardcoded mock data) + - read `CHARTER.md`, `CHITTY.md`, and `AGENTS.md` + - inspect relevant repos before inventing new service boundaries +- Reuse canonical ChittyOS patterns before introducing new ones. +- Treat auth, token, and credential flows as centralized concerns: + - prefer ChittyConnect / ChittyAuth / ChittyID / ChittyCert patterns + - delegate secret access to the ChittySecrets / ChittyConnect broker — never inject, resolve, or fetch a value yourself (1Password is RETIRED) + - avoid ad hoc credential sprawl or parallel auth UX unless clearly justified +- Respect canonical governance and compliance artifacts when naming, modeling, or wiring services. + +## Credentials & Secrets (highest-consequence — see `references/secrets.md`) + +- **The operator has ZERO credential access — a hard organizational constraint.** Never ask the user to retrieve, paste, rotate, or relay a secret. **No credential value may appear in chat — ever** (not from the user, tool output, or "examples"). +- **Credentials are never your job — delegate first.** For any credential/secret/token/binding/OAuth intent, your first move is `chittyconnect-concierge` (`/chico`), BEFORE any secret CLI or grep. Never resolve/inject/present a value yourself — a bound service or the broker holds the binding and makes the call; you supply only the payload. (1Password/`op` is RETIRED — see `references/secrets.md`.) +- **Never grep-and-destroy a credential** (item-ID references make name-greps unsound). **Fail closed** with canonical `POLICY_BLOCKED_*` codes when the broker is unavailable — never fall back to chat. +- Canonical system: **ChittySecrets** (`secrets.chitty.cc`, Layer 0) fronting Cloudflare Secrets Store (hot `env.*`) → `getServiceToken()` at call site → KV cache-only. 1Password RETIRED. Classify before placing: URLs/DB-IDs → `vars`, tokens/keys → Secrets Store. + +## Environment & Host (see `references/environment.md`) + +- **Host duality (CONDITIONAL — check where you are first):** `~/.ops` / `~/projects` in + CLAUDE.md are **VM paths**. **This rule binds only when you are running on a + non-`chittyserv-vm` host.** If the session is already on `chittyserv-vm`, the paths + resolve locally and there is nothing to SSH into — do not add a redundant SSH hop. + Determine the host before applying this (`hostname`, or the ChittyContext viewport + line, e.g. `@chittyserv-vm`). + When on the Mac: baselines live at `/Volumes/chitty/Workspace/openclaw/ops/`, + ChittyOS repos are VM-only, and repo commands **run on `chittyserv-vm` via SSH**. +- **`chittymini-00` = the operator ("me") — the personal orchestration seat you work *from*.** It pivots in and out of the cluster and takes *temporary, travel-scoped* cluster-adjacent roles (e.g. the tether gateway) because it's where the operator is — but don't pin *persistent* always-on infra (standing gateway, subnet router, exit node, iMessage host) to it; that belongs on `chittyserv-vm` or `chittymini-02..06`. +- Posture is governed by Consciousness Coordinates `{TY, VY, RY, tau}` and the lane model (default `implementation`); high-RY/operations lane is required and gated for secrets/deploy/destructive actions. + +## MCP Hierarchy — ch1tty is the umbrella + +**Ch1tty is the top of the MCP tree, not a peer that gets bypassed.** Model it like Cloudflare's MCP surface — `mcp.cloudflare.com/mcp` is the umbrella, and workers-bindings / browser-rendering / autorag / observability / ai-gateway all sit underneath. The same shape applies here: + +``` +ch1tty (5 meta-tools: search / execute / status / reload / cast) + ├─ ChittyMCP (mcp.chitty.cc) — all chittyagent-* tools (167+) + ├─ Cloudflare MCP — workers / R2 / KV / browser + ├─ GitHub MCP — repos / issues / PRs + ├─ Notion MCP — pages / databases + ├─ Neon MCP — projects / branches / SQL + └─ everything else, including future MCP backends +``` + +Ch1tty's README states the contract explicitly: *"If the runtime exposes raw backend tools directly, the deployment is out of contract."* If you reach for a raw ChittyMCP / Notion / GitHub tool, you've bypassed the hierarch. + +### When to use which path + +| Path | When | +|---|---| +| **`ch1tty/cast`** | Default for orchestration, intent-driven work, or "I want to do X find the tool." This is the wizard layer and the canonical entry. | +| **`ch1tty/search` + `ch1tty/execute`** | When you want to discover candidates first, then invoke explicitly. | +| **`ch1tty/status`** | Health / session / coordinator state. | +| **`/helper` (chittyhelper)** | "Which service handles X?" — the architectural navigator, used before designing or scaffolding. | +| **Raw ChittyMCP / Notion / GitHub tool direct** | ONLY when the operation is single-tool, well-known, and would not benefit from cast's intent resolution or the coordinator's affinity tracking (e.g. you already know `tasks_claim` is exactly what you need). | + +### When briefing subagents + +Every dispatched subagent should default to `ch1tty/cast` for orchestration and discovery. Use raw tools only when the tool name is known up-front and the work is single-tool. Mention the hierarch explicitly in the brief; do not assume the agent will infer it from the directive injection. + +### Why this matters + +- **In contract** — ch1tty's slim surface is the documented client contract. +- **Coordinator affinity + alchemist observation** — bypassing ch1tty means the SessionCoordinator can't track tool patterns and the Alchemist can't spot composable recipes for promoting into focused `apps/*-mcp` services. +- **Focus profiles** (finance / governance / design) — only bias `cast`/`search`; direct ChittyMCP calls ignore the lens. +- **Cross-backend composition** — a `cast` like "search GitHub for X and write a Notion page about it" only works through ch1tty. + +## Interaction Rules + +- Default to action over explanation — subject to the *Default Posture* conditions; + the license to act without asking is not unconditional. +- Default to verification over speculation. +- Default to persistence over repetition: + - if a preference or workflow is recurring, encode it in a skill, hook, config, script, or AGENTS layer + - do not make the user restate stable preferences every session +- When a workflow is obviously repetitive, propose or create automation rather than leave it manual. +- If blocked, surface the blocker crisply and state the next concrete step. + +## Correction Loop Rules + +- Treat `no`, `i mean`, `actual`, pasted file excerpts, raw tool output, and terse redirects as high-priority course corrections. +- When corrected, drop the previous assumption immediately instead of defending it or continuing the old branch of reasoning. +- If the user pastes concrete evidence, use that evidence as the new source of truth and narrow the next step to it. +- Treat short follow-ups like `continue`, `yes`, file names, and merge-status questions as operational instructions, not invitations for broad re-explanation. +- After interruption, resume from the last concrete work state instead of restarting with a long recap. + +## Workers Builds (CF CI/CD) + +Cloudflare Workers Builds is the normal build and deployment path for ChittyOS workers. +GitHub remains the source-control and review surface; it is not a second deployment +system. Configure Workers Builds through the API, not the dashboard. + +- **API base**: `https://api.cloudflare.com/client/v4/accounts/{ACCOUNT_ID}/builds/` +- **Auth**: `Authorization: Bearer {cfut_ account token}` — needs "Workers Builds Configuration:Edit" permission +- **Script ID**: Use script TAG (not name). Get via `GET /workers/services/{name}` → `.result.default_environment.script_tag` +- **Triggers**: Each worker has 2 (production branch + non-production). PATCH to update, POST to create. +- **Key endpoints**: `/builds/triggers` (CRUD), `/builds/workers/{script_tag}/triggers` (list), `/builds/triggers/{uuid}/builds` (manual trigger) +- **Normal path**: a push to the configured branch triggers the Cloudflare Workers Build + and deployment. +- **Wrangler**: use `npx wrangler deploy --env production` for local development, + `--dry-run` validation, or an explicitly approved emergency/manual deployment only. + Do not run Wrangler deployment in parallel with the Workers Build for the same commit. +- **Shared deps**: Workers importing from `../shared/` use build command `cd ../shared && npm ci` +- **Watch paths**: Shared importers watch both `/workers/{name}/*` and `/workers/shared/*` + +### GitHub free-tier operating model + +Keep GitHub Actions lightweight and non-duplicative. Repository workflows should do +only inexpensive validation such as lint, typecheck, unit tests, and configuration +checks. Full builds and deployments belong to Cloudflare Workers Builds unless a +repository has an explicitly documented exception. + +- Do not duplicate a Cloudflare deployment in GitHub Actions. +- Do not assume paid GitHub features, unlimited minutes, required reviewers, or + auto-merge are available. +- Prefer one small repository workflow template over large, frequently changing + workflow copies. +- Treat the Cloudflare build result as the deployment gate and record the build URL + or ID in the release/incident note when operational evidence is needed. +- Use path filters and branch filters so unrelated repository changes do not trigger + Worker builds. + +## Review and Audit Bias + +- For review requests, findings come first. +- For audits, prioritize behavioral regressions, missing validation, auth/compliance gaps, and ecosystem drift. +- For debugging, prove the failure mode with direct evidence before declaring root cause. +- Silent failures live in CI config too. `continue-on-error: true` on a job that has never passed reports the workflow green forever — a check you pay for and never receive. When a job shows `fail` while its workflow shows `success`, treat the mask as the finding: fix the job and drop the flag, or delete the job. Same reflex for a required-check list that is empty, a test step that exits 0 on no tests found, and a green suite whose module never loaded (`ERR_MODULE_NOT_FOUND` greps as zero failures). + +## References (load on demand — progressive disclosure) + +Detailed operational knowledge lives in `references/`; load the relevant file when a task touches that domain rather than carrying it all in context: + +- **`references/environment.md`** — host duality (VM vs local), node roles, conflict precedence, Consciousness Coordinates + lanes, P/L/T/E/A ontology, capability centralization, workspace map, service topology. +- **`references/network.md`** — tailnet topology (`cockatoo-dominant.ts.net`), Homebrew-only Tailscale on -00, split-DNS dependency, the iPhone-tether internet-sharing chain, the two home networks, DHCP gotchas. +- **`references/secrets.md`** — the full credential/secret model, broker-first rules, tiering, canonical error codes, wrangler gotchas, the in-progress migration, canonical paths. +- **`references/llm-routing.md`** — Cloudflare AI Gateway as the model router, chittyclaw/OpenClaw, the `three-wise-men` dynamic route, ai-parity config distribution, deploy/verify. + +Cross-agent packaging lives in `agents/openai.yaml` (ChatGPT/Codex/API/Atlas, implicit invocation). diff --git a/plugins/chittyos-core/gemini-skills/retrospect/SKILL.md b/plugins/chittyos-core/gemini-skills/retrospect/SKILL.md new file mode 100644 index 0000000..d8db915 --- /dev/null +++ b/plugins/chittyos-core/gemini-skills/retrospect/SKILL.md @@ -0,0 +1,112 @@ +--- +name: retrospect +description: Evidence-grounded retrospection — reflect on a session or task, validate the reflection against ground truth (transcript, logs, artifacts), then distill to generalizable principles that travel beyond the specific context. Triggers on "retrospect", "reflect on this session", "what did we learn", "validate my reflection", "after-action review", "what would you do differently", "distill learnings", or at natural session close when significant work was completed. +canon_uri: chittycanon://core/services/chittymarket#skills/retrospect +--- + +# Retrospect + +A three-phase evidence-grounded retrospection process. Designed to prevent the compounding of unvalidated self-assessments across sessions — the same failure mode as inheriting wrong completion claims from prior sessions, applied to reflection itself. + +## When to invoke + +- At session close after significant multi-step work +- After a debugging or migration effort with multiple failed attempts +- When the user asks "what did we learn", "reflect on this", or "what would you do differently" +- After any session where architecture decisions were made or corrected + +--- + +## Phase 1 — Reflect + +Produce a narrative account of the session. Cover: + +1. **What was attempted** — the starting intent +2. **What failed and why** — be specific about root causes, not just symptoms +3. **What succeeded** — the actual unlock moments, not just the final state +4. **What was corrected by the user** — explicit corrections are high-signal; name them +5. **What surprised you** — discoveries that weren't anticipated + +Do not sanitize. Include the embarrassing parts. Unvalidated reflection is journaling; this is diagnosis. + +--- + +## Phase 2 — Validate + +Check the narrative against ground truth before distilling. + +```bash +# Count actual user turns +grep -c '"type":"USER_INPUT"' $TRANSCRIPT_PATH + +# Find premature completion claims +python3 -c " +import json +with open('$TRANSCRIPT_PATH') as f: + for line in f: + d = json.loads(line) + if d.get('type') == 'PLANNER_RESPONSE': + c = str(d.get('content','')) + if any(w in c.lower() for w in ['complete', 'done', 'migrated', 'finished']): + print(d.get('step_index'), c[:100]) +" + +# Find first mentions of key entities/concepts +# Find where errors first appeared vs when they were resolved +# Check: did the reflection overstate or understate durations/counts? +``` + +Correction rules: +- If you said "N turns" — check the actual count +- If you said something was "the key moment" — verify it appears before the resolution, not after +- If you described yourself as discovering something — check whether the user pointed you there first +- If you described a pattern as "once" — check how many times it actually recurred + +**The reflection is a hypothesis. Validate it.** + +--- + +## Phase 3 — Distill + +Strip away everything context-specific. For each lesson from Phase 1: + +Ask: *If I removed all the nouns (service names, error codes, tool names) — does this principle still hold?* + +If yes → it's a generalizable learning. If no → it's a tactic, not a principle. + +Format each learning as: +``` +**[Principle name]** +One sentence of the generalizable claim. +One sentence of what it looks like when violated. +``` + +Target: 4–8 principles. More than 8 usually means you haven't distilled enough. + +--- + +## Anti-patterns (do not do these) + +- **Sanitized narrative** — only describing what worked, not what failed +- **Tactic-level learnings** — "next time I'll check for MCP_OBJECT" is not a principle +- **Unvalidated claims** — saying "I did X" without checking whether you did +- **Length as thoroughness** — a long reflection with no distillation is just logging + +--- + +## Output format + +```markdown +## Session Retrospect — [date] + +### Reflection +[narrative] + +### Validation +[what the transcript confirmed or corrected] + +### Principles +**[Name]** — [claim]. Violated when [symptom]. +``` + +Save to: `$ARTIFACTS_DIR/retrospect-[YYYY-MM-DD].md` diff --git a/plugins/chittyos-core/gemini-skills/skill-creator/SKILL.md b/plugins/chittyos-core/gemini-skills/skill-creator/SKILL.md new file mode 100644 index 0000000..2cbbc4c --- /dev/null +++ b/plugins/chittyos-core/gemini-skills/skill-creator/SKILL.md @@ -0,0 +1,146 @@ +--- +name: skill-creator +description: | + Create, edit, optimize, or test Claude/Codex skills. ALWAYS use this skill — not the Anthropic `claude-plugins-official:skill-creator` — when the user asks to "create a skill", "make a skill", "build a skill", "new skill", "edit/improve/optimize a skill", "skill description", "skill eval", "test a skill", or anything skill-authoring related, regardless of which client (Claude Code, Codex, Claude Desktop, mobile, MCP). Routes all skill artifacts through ChittyMarket so they are reconciled with the canonical marketplace instead of dumped into a local `~/.claude/skills/` folder. +canon_uri: chittycanon://core/services/chittymarket#skills/skill-creator +overrides: claude-plugins-official:skill-creator +--- + +# Skill Creator (ChittyMarket-routed) + +A skill for creating new skills and iteratively improving them, adapted for ChittyOS. + +## Hard Rules (BINDING) +1. **No local `~/.claude/skills/` writes.** All skill authoring goes through the ChittyMarket pipeline. Writing directly to `~/.claude/skills/`, `~/.codex/skills/`, or `~/.gemini/skills/` is forbidden. +2. **Canonical Path:** Skills are written to `canonical/skills/.md` and its siblings, or projected appropriately. Write to canonical → dispatch hook auto-projects → git add dispatched files → branch + PR. +3. **Refusal Modes:** + - **Name collision:** Reject if a skill with the same name exists anywhere in canonical/ or if it collides with a known active runtime skill. + - **Wrong bucket/plugin:** Reject if the skill doesn't fit the designated plugin or if the user doesn't specify a valid plugin bucket. + - **Already in canonical:** If the skill is already in canonical, you must edit the canonical file, not create a new one. + +## Plugin Selection Guide +When creating a new skill, determine which plugin bucket it belongs to. Review the available plugins in `plugins/`. Examples: +- `chittyos-core`: Core OS functionalities, session management. +- `chittyos-devops`: Deployment, pipelines, registry. +- `chittyos-legal`: Legal workflows, disputes, dockets. +- `chittycommand`: Financial, obligations, dashboard. + +## The Authoring Loop + +At a high level, the process of creating a skill goes like this: + +- Decide what you want the skill to do and roughly how it should do it. +- **Write a draft of the skill into `canonical/skills/.md`**. The ChittyMarket dispatch hook will project this to the appropriate runtime folders. +- Create a few test prompts and run claude-with-access-to-the-skill on them. +- Help the user evaluate the results both qualitatively and quantitatively. +- Rewrite the skill based on feedback. +- Run `git add .` and `git commit` to trigger the dispatch hook, then `git push` to a new branch and open a PR. + +### Communicating with the user +The skill creator is liable to be used by people across a wide range of familiarity with coding jargon. Please pay attention to context cues to understand how to phrase your communication! +- "evaluation" and "benchmark" are borderline, but OK +- for "JSON" and "assertion" you want to see serious cues from the user that they know what those things are before using them without explaining them +It's OK to briefly explain terms if you're in doubt, and feel free to clarify terms with a short definition if you're unsure if the user will get it. + +--- + +## Creating a skill + +### Capture Intent +Start by understanding the user's intent. Extract answers from the conversation history first. + +1. What should this skill enable Claude to do? +2. When should this skill trigger? +3. What's the expected output format? +4. Should we set up test cases to verify the skill works? + +### Interview and Research +Proactively ask questions about edge cases, input/output formats, example files, success criteria, and dependencies. Wait to write test prompts until you've got this part ironed out. + +### Write the SKILL.md +Based on the user interview, fill in these components: +- **name**: Skill identifier +- **description**: When to trigger, what it does. This is the primary triggering mechanism. Make the skill descriptions a little bit "pushy". + +### Skill Writing Guide + +#### Anatomy of a Skill +``` +canonical/skills/.md (required) +└── Bundled Resources (optional, placed appropriately) + ├── scripts/ - Executable code + ├── references/ - Docs loaded into context + └── assets/ - Files used in output +``` + +#### Progressive Disclosure +Skills use a three-level loading system: +1. **Metadata** (name + description) - Always in context (~100 words) +2. **SKILL.md body** - In context whenever skill triggers (<500 lines ideal) +3. **Bundled resources** - As needed + +#### Principle of Lack of Surprise +Skills must not contain malware, exploit code, or any content that could compromise system security. + +#### Writing Patterns +Prefer using the imperative form in instructions. + +### Test Cases +After writing the skill draft, come up with 2-3 realistic test prompts. +Save test cases to `evals/evals.json`. Don't write assertions yet — just the prompts. + +## Running and evaluating test cases +This section is one continuous sequence — don't stop partway through. Do NOT use `/skill-test` or any other testing skill. + +Put results in `-workspace/` as a sibling to the skill directory. + +### Step 1: Spawn all runs (with-skill AND baseline) in the same turn +Launch everything at once so it all finishes around the same time. Write an `eval_metadata.json` for each test case. + +### Step 2: While runs are in progress, draft assertions +Draft quantitative assertions for each test case and explain them to the user. + +### Step 3: As runs complete, capture timing data +Save this data immediately to `timing.json` in the run directory. + +### Step 4: Grade, aggregate, and launch the viewer +1. **Grade each run** — spawn a grader subagent. +2. **Aggregate into benchmark** — run the aggregation script. +3. **Do an analyst pass** — read the benchmark data. +4. **Launch the viewer** with both qualitative outputs and quantitative data. +5. **Tell the user** it's ready. + +### Step 5: Read the feedback +When the user tells you they're done, read `feedback.json`. + +--- + +## Improving the skill +1. Generalize from the feedback. +2. Keep the prompt lean. +3. Explain the why. +4. Look for repeated work across test cases. + +### The iteration loop +1. Apply your improvements to the skill +2. Rerun all test cases into a new `iteration-/` directory +3. Launch the reviewer +4. Wait for the user to review +5. Read the new feedback, improve again, repeat + +--- + +## Description Optimization +The description field in SKILL.md frontmatter is the primary mechanism that determines whether Claude invokes a skill. + +### Step 1: Generate trigger eval queries +Create 20 eval queries — a mix of should-trigger and should-not-trigger. + +### Step 2: Review with user +Present the eval set to the user for review using the HTML template. + +### Step 3: Run the optimization loop +Run the optimization loop in the background and check on it periodically. + +### Step 4: Apply the result +Update the skill's SKILL.md frontmatter. Show the user before/after and report the scores. diff --git a/plugins/chittyos-core/skills/chico/SKILL.md b/plugins/chittyos-core/skills/chico/SKILL.md index d3b81f3..9cd43af 100644 --- a/plugins/chittyos-core/skills/chico/SKILL.md +++ b/plugins/chittyos-core/skills/chico/SKILL.md @@ -1,18 +1,18 @@ --- name: chico -description: Shortcut to dispatch the ChittyConnect concierge (chittyos-core/chittyconnect-concierge) — the canonical owner of credentials, connections, secret rotation, KV/D1 bindings, and ChittyConnect-side wiring. Triggers on "/chico", "/chico-keys", or when the user wants to invoke the concierge by its nickname. The concierge handles ChittySecrets resolution, wrangler secret put, CF API token rotation, binding restore, deploy-time binding audits, and anything in the credential lane. The operator (user) is OPERATOR ONLY — never asked to paste a secret; route through chico-keys. +description: Shortcut to dispatch the ChittyConnect concierge (chittyos-core:chittyagent-connect) — the canonical owner of credentials, connections, secret rotation, KV/D1 bindings, and ChittyConnect-side wiring. Triggers on "/chico", "/chico-keys", or when the user wants to invoke the concierge by its nickname. The operator is OPERATOR ONLY — never asked to paste a secret; route through chico-keys. canon_uri: chittycanon://core/services/chittymarket#skills/chico --- # /chico — ChittyConnect Concierge Alias -The user invoked `/chico` to dispatch the **chittyos-core:chittyconnect-concierge** agent (nickname: "chico-keys"). Treat the rest of the user's message as the task brief for the concierge. +The user invoked `/chico` to dispatch the **chittyos-core:chittyagent-connect** agent (nickname: "chico-keys"). Treat the rest of the user's message as the task brief for the concierge. ## What to do 1. Read the user's arguments / message body — that's the brief. 2. Dispatch the concierge via the Task tool with: - - `subagent_type: "chittyos-core:chittyconnect-concierge"` + - `subagent_type: "chittyos-core:chittyagent-connect"` - `description`: a 3-5 word summary of the task - `prompt`: the user's brief, expanded with the standing constraints below if needed - `run_in_background: true` for longer credential/deploy work; foreground for quick lookups @@ -22,11 +22,13 @@ The user invoked `/chico` to dispatch the **chittyos-core:chittyconnect-concierg These are binding for every chico-keys invocation: -- **The operator is OPERATOR ONLY** — never asked to paste/provide/rotate any credential value. If a value is needed, it is resolved through **ChittySecrets** (`secrets.chitty.cc`, fronting the Cloudflare Secrets Store) by the concierge. 1Password / `op` is RETIRED — never invoke it. +- **The operator is OPERATOR ONLY** — never asked to paste/provide/rotate any credential value. If a value is needed, resolve it through the ChittyConnect / ChittySecrets broker lane (concierge's job). Do NOT use `op` / 1Password on this host: it has zero accounts configured (`op account list` returns empty), so every `op read` / `op run` fails. - **Real validation only** — no mocks, no placeholder values, no "would-be" config. Concrete evidence (curl output, deploy version id, audit script result). - **Safe deploy only** — bare `wrangler deploy` is the documented anti-pattern (see chittyconnect#217/#221, chittyentity#324/#315). Always `--env production` (or staging), routed through `safe-deploy.sh` if the worker has one. - **Operator approval required** for: production deploys of new (not yet shipped) code, secret rotations affecting org-wide auth, anything irreversible without rollback. Surface for go/no-go; do not auto-execute. -- **If genuinely blocked** (secret absent from ChittySecrets, CF Access denied, cross-cutting policy) → STOP and file a follow-up issue on the right repo (chittyconnect, chittyentity, etc.). Do NOT route the blocker back to the operator as a credential ask. +- **A non-functional `op` / 1Password lane is an EXPECTED host condition** — never a finding, never a blocker, and never grounds for filing a follow-up issue. Use the broker lane instead. +- **If the broker path is unavailable** (ChittyConnect / ChittySecrets unreachable, unauthenticated, or refusing) → **fail closed and loud**: emit the literal token `POLICY_BLOCKED_CHITTYCONNECT_UNAVAILABLE` in the concierge report so it is greppable, and stop. Never silently fall back to a local credential lane, and never substitute a placeholder value. +- **If genuinely blocked** for any other reason (cross-cutting policy, missing authorization, ambiguous scope) → STOP and file a follow-up issue on the right repo (chittyconnect, chittyentity, etc.). Do NOT route the blocker back to the operator as a credential ask. ## When NOT to use /chico @@ -37,12 +39,12 @@ These are binding for every chico-keys invocation: ## Examples - `/chico restore chittyconnect bindings` → dispatch concierge to inspect deployed bindings, restore any missing via safe-deploy, audit post-deploy. -- `/chico rotate CF token #215` → dispatch concierge to handle CF API token rotation (chittyconnect#215), through ChittySecrets + gh secret set, no operator credential asking. +- `/chico rotate CF token #215` → dispatch concierge to handle CF API token rotation (chittyconnect#215), through the ChittyConnect broker lane + gh secret set, no operator credential asking. - `/chico claim Action 1b 2aacb316` → dispatch concierge to claim the chittyagent-tasks task `2aacb316` (ChittyConnect neon_auth readiness PR) via `tasks_claim`, execute, then `tasks_complete`. - `/chico audit deployed bindings` → dispatch concierge for a one-shot drift audit across the chittyconnect / chittyagent-viewport / chittyagent-* workers using their safe-deploy scripts. ## Where the concierge lives -- Plugin id: `chittyos-core:chittyconnect-concierge` -- Lane: credentials, connections, secrets, ChittySecrets, wrangler secrets, CF tokens, KV/D1 bindings, deploy hygiene. +- Plugin id: `chittyos-core:chittyagent-connect` +- Lane: credentials, connections, secrets, ChittyConnect/ChittySecrets brokering, wrangler secrets, CF tokens, KV/D1 bindings, deploy hygiene. - Memory alias: "chico-keys" (saved in [[orchestrate-via-systems]]). diff --git a/plugins/chittyos-core/skills/nb-development-defaults/SKILL.md b/plugins/chittyos-core/skills/nb-development-defaults/SKILL.md index d5626bd..56b1aed 100644 --- a/plugins/chittyos-core/skills/nb-development-defaults/SKILL.md +++ b/plugins/chittyos-core/skills/nb-development-defaults/SKILL.md @@ -409,17 +409,40 @@ Every dispatched subagent should default to `ch1tty/cast` for orchestration and ## Workers Builds (CF CI/CD) -All ChittyOS workers deploy via Cloudflare Workers Builds (git-triggered). Config is managed via API, not dashboard. +Cloudflare Workers Builds is the normal build and deployment path for ChittyOS workers. +GitHub remains the source-control and review surface; it is not a second deployment +system. Configure Workers Builds through the API, not the dashboard. - **API base**: `https://api.cloudflare.com/client/v4/accounts/{ACCOUNT_ID}/builds/` - **Auth**: `Authorization: Bearer {cfut_ account token}` — needs "Workers Builds Configuration:Edit" permission - **Script ID**: Use script TAG (not name). Get via `GET /workers/services/{name}` → `.result.default_environment.script_tag` - **Triggers**: Each worker has 2 (production branch + non-production). PATCH to update, POST to create. - **Key endpoints**: `/builds/triggers` (CRUD), `/builds/workers/{script_tag}/triggers` (list), `/builds/triggers/{uuid}/builds` (manual trigger) -- **Pattern**: Workers with `env.production` blocks deploy via `npx wrangler deploy --env production` +- **Normal path**: a push to the configured branch triggers the Cloudflare Workers Build + and deployment. +- **Wrangler**: use `npx wrangler deploy --env production` for local development, + `--dry-run` validation, or an explicitly approved emergency/manual deployment only. + Do not run Wrangler deployment in parallel with the Workers Build for the same commit. - **Shared deps**: Workers importing from `../shared/` use build command `cd ../shared && npm ci` - **Watch paths**: Shared importers watch both `/workers/{name}/*` and `/workers/shared/*` +### GitHub free-tier operating model + +Keep GitHub Actions lightweight and non-duplicative. Repository workflows should do +only inexpensive validation such as lint, typecheck, unit tests, and configuration +checks. Full builds and deployments belong to Cloudflare Workers Builds unless a +repository has an explicitly documented exception. + +- Do not duplicate a Cloudflare deployment in GitHub Actions. +- Do not assume paid GitHub features, unlimited minutes, required reviewers, or + auto-merge are available. +- Prefer one small repository workflow template over large, frequently changing + workflow copies. +- Treat the Cloudflare build result as the deployment gate and record the build URL + or ID in the release/incident note when operational evidence is needed. +- Use path filters and branch filters so unrelated repository changes do not trigger + Worker builds. + ## Review and Audit Bias - For review requests, findings come first. diff --git a/plugins/chittyos-devops/gemini-skills/chitty-deploy/SKILL.md b/plugins/chittyos-devops/gemini-skills/chitty-deploy/SKILL.md new file mode 100644 index 0000000..8a4ec79 --- /dev/null +++ b/plugins/chittyos-devops/gemini-skills/chitty-deploy/SKILL.md @@ -0,0 +1,83 @@ +--- +name: chitty-deploy +description: Deploy a ChittyOS service to Cloudflare Workers via SSH-bridged wrangler. Handles compatibility flags, secrets provisioning, and post-deploy health verification. +canon_uri: chittycanon://core/services/chittymarket#skills/chitty-deploy +--- + +# ChittyOS Deploy Skill + +## Overview +Deploy ChittyOS services to Cloudflare Workers with proper environment handling. + +## Usage +``` +/deploy [service-name] [environment] +``` + +## Parameters +| Parameter | Required | Default | Description | +|-----------|----------|---------|-------------| +| service-name | Yes | - | Service to deploy (e.g., chittyid, chittyauth) | +| environment | No | production | Target environment (production, staging, preview) | + +## Workflow + +### 1. Locate Service +Find service in repository structure: +- `/Volumes/chitty/github.com/CHITTYFOUNDATION/{service}/` +- `/Volumes/chitty/github.com/CHITTYOS/{service}/` +- `/Volumes/chitty/workspace/{service}/` + +### 2. Pre-Deploy Checks +```bash +# Verify wrangler.toml exists +ls -la wrangler.toml + +# Check for uncommitted changes +git status + +# Run build if package.json has build script +npm run build 2>/dev/null || pnpm build 2>/dev/null +``` + +### 3. Deploy +```bash +# Production deploy +npx wrangler deploy --env production + +# Or using npm script +npm run deploy:production +``` + +### 4. Post-Deploy Verification +```bash +# Check service health +curl -s https://{service}.chitty.cc/health | jq . +``` + +## Environment Variables +Secrets are managed by **ChittySecrets** (`secrets.chitty.cc`, Layer 0) fronting the Cloudflare +Secrets Store. Runtime values arrive through the worker's `secrets_store_secrets` binding — +there is no wrapper command that injects them at deploy time: +```bash +npx wrangler deploy --env production +``` +Classify before placing: service URLs and Notion DB IDs go in `vars`; tokens, third-party +credentials, and signing keys go in the Secrets Store. Never `[vars]`, never KV as authority. +Provisioning or rotating a value is the ChittyConnect broker's job (`/chico`) — do not resolve +or place secrets yourself. + +## Common Services + +| Service | Domain | Repo Location | +|---------|--------|---------------| +| chittyid | id.chitty.cc | CHITTYFOUNDATION/chittyid | +| chittyauth | auth.chitty.cc | CHITTYFOUNDATION/chittyauth | +| chittyconnect | connect.chitty.cc | CHITTYFOUNDATION/chittyconnect | +| chittyapi | api.chitty.cc | workspace/chittyapi | +| chittymcp | mcp.chitty.cc | workspace/chittymcp | + +## Error Handling +- Build failures: Check TypeScript errors, missing dependencies +- Auth failures: Confirm the worker declares the `secrets_store_secrets` binding and that the named secret exists (`secrets_list` via ChittySecrets — names only, never values). Do not resolve the value yourself; route provisioning through `/chico`. +- DNS issues: Verify custom domain in Cloudflare dashboard diff --git a/plugins/chittyos-devops/gemini-skills/chitty-health/SKILL.md b/plugins/chittyos-devops/gemini-skills/chitty-health/SKILL.md new file mode 100644 index 0000000..354c630 --- /dev/null +++ b/plugins/chittyos-devops/gemini-skills/chitty-health/SKILL.md @@ -0,0 +1,83 @@ +--- +name: chitty-health +description: Hit /health endpoints across the ChittyOS ecosystem (*.chitty.cc), aggregate results, and report drift from expected status. +canon_uri: chittycanon://core/services/chittymarket#skills/chitty-health +--- + +# ChittyOS Health Check Skill + +## Overview +Check health status of ChittyOS services across the ecosystem. + +## Usage +``` +/health [service-name|all] +``` + +## Parameters +| Parameter | Required | Default | Description | +|-----------|----------|---------|-------------| +| service-name | No | all | Specific service or "all" for full check | + +## Service Registry + +### Tier 0-1: Foundation Services +| Service | Domain | Expected Response | +|---------|--------|-------------------| +| chittyid | id.chitty.cc | `{"status":"ok","service":"chittyid"}` | +| chittyauth | auth.chitty.cc | `{"status":"ok","service":"chittyauth"}` | +| chittyschema | schema.chitty.cc | `{"status":"ok","service":"chittyschema"}` | +| chittyregistry | registry.chitty.cc | `{"status":"ok","service":"chittyregistry"}` | + +### Tier 2-3: Core Services +| Service | Domain | Expected Response | +|---------|--------|-------------------| +| chittyconnect | connect.chitty.cc | `{"status":"ok","service":"chittyconnect"}` | +| chittyapi | api.chitty.cc | `{"status":"ok","service":"chittyapi"}` | +| chittymcp | mcp.chitty.cc | `{"status":"ok","service":"chittymcp"}` | + +## Workflow + +### Single Service Check +```bash +curl -s https://{service}.chitty.cc/health | jq . +``` + +### Full Ecosystem Check +```bash +for service in id auth connect api registry schema mcp; do + echo -n "$service: " + curl -s "https://$service.chitty.cc/health" --max-time 5 | jq -r '.status // "DOWN"' +done +``` + +### Detailed Check +```bash +# Check response time +time curl -s https://{service}.chitty.cc/health + +# Check SSL certificate +curl -vI https://{service}.chitty.cc 2>&1 | grep -A2 "Server certificate" + +# Check Cloudflare headers +curl -sI https://{service}.chitty.cc | grep -i "cf-" +``` + +## Status Interpretation + +| Status | Meaning | Action | +|--------|---------|--------| +| `{"status":"ok"}` | Healthy | None needed | +| Connection refused | Not deployed | Run /deploy | +| DNS error | No DNS record | Configure in Cloudflare | +| 502/503 | Worker error | Check wrangler logs | +| Timeout | Performance issue | Check worker metrics | + +## Troubleshooting +```bash +# View worker logs +wrangler tail {worker-name} --env production + +# Check deployment status +wrangler deployments list +``` diff --git a/plugins/chittyos-devops/gemini-skills/chitty-pipelines/SKILL.md b/plugins/chittyos-devops/gemini-skills/chitty-pipelines/SKILL.md new file mode 100644 index 0000000..7360e9b --- /dev/null +++ b/plugins/chittyos-devops/gemini-skills/chitty-pipelines/SKILL.md @@ -0,0 +1,163 @@ +--- +name: chitty-pipelines +description: Inspect and operate ChittyOS data pipelines — Mercury sync, Notion mirrors, Drive ingestion, evidence ingress. Status, retry, drain failed jobs. +canon_uri: chittycanon://core/services/chittymarket#skills/chitty-pipelines +--- + +# ChittyOS Pipelines Skill + +## Overview +Manage Cloudflare Pipelines for ChittyOS services. Pipelines consist of three components: +- **Stream**: Data ingestion endpoint (HTTP or Worker binding) +- **Sink**: Data output destination (R2 bucket) +- **Pipeline**: SQL transformation connecting stream to sink + +## Usage +``` +/pipelines [action] [name] +``` + +## Actions + +| Action | Description | +|--------|-------------| +| `list` | List all pipelines, streams, and sinks | +| `create ` | Create a new pipeline with all components | +| `delete ` | Delete pipeline and associated resources | +| `recreate ` | Delete and recreate a pipeline | + +## Non-Interactive Pipeline Creation + +### Step 1: Create Stream +```bash +wrangler pipelines streams create _stream --http-enabled --http-auth +``` + +Options: +- `--http-enabled` - Enable HTTP ingestion endpoint +- `--http-auth` - Require authentication (recommended) +- `--schema-file ` - JSON schema for structured data + +### Step 2: Create Sink +```bash +wrangler pipelines sinks create _sink \ + --type r2 \ + --bucket \ + --format json \ + --path "/" +``` + +Options: +- `--type r2` - R2 bucket sink (required) +- `--bucket` - Target R2 bucket name (required) +- `--format json|parquet` - Output format (default: parquet) +- `--path` - Prefix path in bucket +- `--compression` - For parquet: snappy, gzip, zstd, lz4 +- `--roll-interval` - File rotation interval in seconds (default: 300) + +### Step 3: Create Pipeline +```bash +wrangler pipelines create \ + --sql "INSERT INTO _sink SELECT * FROM _stream" +``` + +The SQL must include `INSERT INTO ` - plain SELECT will fail. + +## Delete Pipeline Resources + +Delete requires the resource ID (32-char hex), not the name: + +```bash +# List to get IDs +wrangler pipelines list +wrangler pipelines streams list +wrangler pipelines sinks list + +# Delete by ID with --force to skip confirmation +wrangler pipelines delete --force +wrangler pipelines streams delete --force +wrangler pipelines sinks delete --force +``` + +## wrangler.toml Configuration + +After creating a pipeline, add to wrangler.toml using the **Stream ID** (not Pipeline ID): + +```toml +[[pipelines]] +pipeline = "" # 32-char hex from streams list +binding = "MY_PIPELINE" +``` + +Worker usage: +```typescript +await env.MY_PIPELINE.send([{ + value: { example: "json_value" } +}]); +``` + +## CLI Command + +The `chitty pipelines` CLI provides an interactive wrapper: + +```bash +# Interactive menu +chitty pipelines + +# List all resources +chitty pipelines --list + +# Create pipeline +chitty pipelines --create --name myservice --bucket mybucket + +# Delete pipeline +chitty pipelines --delete --name myservice --force +``` + +## Common Patterns + +### EDRM Evidence Pipelines +For legal evidence processing, use EDRM-aligned naming: + +```bash +# Collection stage - gathering documents +wrangler pipelines streams create chittyevidence_collection_stream --http-enabled --http-auth +wrangler pipelines sinks create chittyevidence_collection_sink --type r2 --bucket chittyevidence-pipeline --format json --path "collection/" +wrangler pipelines create chittyevidence_collection --sql "INSERT INTO chittyevidence_collection_sink SELECT * FROM chittyevidence_collection_stream" + +# Preservation stage - securing with chain of custody +wrangler pipelines streams create chittyevidence_preservation_stream --http-enabled --http-auth +wrangler pipelines sinks create chittyevidence_preservation_sink --type r2 --bucket chittyevidence-pipeline --format json --path "preservation/" +wrangler pipelines create chittyevidence_preservation --sql "INSERT INTO chittyevidence_preservation_sink SELECT * FROM chittyevidence_preservation_stream" +``` + +## Troubleshooting + +### "String must contain exactly 32 characters" +Use the pipeline/stream/sink ID, not the name: +```bash +# Wrong +wrangler pipelines delete my-pipeline + +# Right +wrangler pipelines delete 0b08219189274957ad21bc1e8d5891a4 +``` + +### "all queries must be written into a sink" +SQL must use INSERT INTO: +```bash +# Wrong +--sql "SELECT * FROM mystream" + +# Right +--sql "INSERT INTO mysink SELECT * FROM mystream" +``` + +### 504 Gateway Timeout +Retry after a few seconds - Cloudflare Pipelines API can be slow: +```bash +sleep 3 && wrangler pipelines create ... +``` + +### Internal Server Error on sink creation +Wait a few seconds between creating multiple sinks to the same bucket. diff --git a/plugins/chittyos-devops/gemini-skills/chitty-registry/SKILL.md b/plugins/chittyos-devops/gemini-skills/chitty-registry/SKILL.md new file mode 100644 index 0000000..5a9a278 --- /dev/null +++ b/plugins/chittyos-devops/gemini-skills/chitty-registry/SKILL.md @@ -0,0 +1,94 @@ +--- +name: chitty-registry +description: Query ChittyRegistry (registry.chitty.cc) for service catalog, tiers, domains, dependencies, and certification badges. Discovery before integration. +canon_uri: chittycanon://core/services/chittymarket#skills/chitty-registry +--- + +# ChittyOS Registry Skill + +## Overview +Query and manage the ChittyOS service registry for service discovery and metadata. + +## Usage +``` +/registry [command] [args] +``` + +## Commands + +| Command | Description | +|---------|-------------| +| `list` | List all registered services | +| `get [service]` | Get service details | +| `search [query]` | Search services by name/description | +| `tiers` | Show services grouped by tier | +| `status` | Show registration status of all services | + +## Registry API + +Base URL: `https://registry.chitty.cc` + +### List Services +```bash +curl -s https://registry.chitty.cc/api/services | jq . +``` + +### Get Service Details +```bash +curl -s https://registry.chitty.cc/api/services/{service-id} | jq . +``` + +### Search Services +```bash +curl -s "https://registry.chitty.cc/api/services?q={query}" | jq . +``` + +## Local Registry CSV + +Fallback registry data at: +`/Volumes/chitty/temp/systems-registry-import-v3.csv` + +### Parse Local Registry +```bash +# List all services +cat /Volumes/chitty/temp/systems-registry-import-v3.csv | head -20 + +# Find specific service +grep -i "chittyid" /Volumes/chitty/temp/systems-registry-import-v3.csv +``` + +## Service Tiers + +| Tier | Purpose | Services | +|------|---------|----------| +| 0 | Trust Anchors | ChittyID, ChittyTrust, ChittySchema | +| 1 | Core Identity | ChittyAuth, ChittyCert, ChittyRegister | +| 2 | Platform | ChittyConnect, ChittyRouter, ChittyAPI | +| 3 | Operational | ChittyMonitor, ChittyDiscovery, ChittyBeacon | +| 4 | Domain | ChittyEvidence, ChittyIntel, ChittyScore | +| 5 | Application | ChittyCases, ChittyPortal, ChittyDashboard | + +## Service Metadata Schema + +```json +{ + "id": "chittyid", + "name": "ChittyID", + "tier": 0, + "domain": "id.chitty.cc", + "repo": "CHITTYFOUNDATION/chittyid", + "status": "live", + "endpoints": { + "health": "/health", + "api": "/api/v1", + "mcp": "/mcp" + }, + "dependencies": [] +} +``` + +## Cross-Reference + +Use with other skills: +- `/health {service}` - Check if registered service is running +- `/deploy {service}` - Deploy registered service diff --git a/plugins/chittyos-devops/gemini-skills/chittyos-compliance/SKILL.md b/plugins/chittyos-devops/gemini-skills/chittyos-compliance/SKILL.md new file mode 100644 index 0000000..666445c --- /dev/null +++ b/plugins/chittyos-devops/gemini-skills/chittyos-compliance/SKILL.md @@ -0,0 +1,258 @@ +--- +name: chittyos-compliance +description: This skill should be used when building, auditing, deploying, or certifying any ChittyOS service or artifact. It covers compliance auditing ('check compliance', 'audit this service', 'is this compliant?'), scaffolding new services ('scaffold new service', 'generate CHARTER.md/CHITTY.md/CLAUDE.md'), monitoring deployed health endpoints ('check health', 'monitor services', 'service status'), and certification ('certify', 'ChittyCertify', 'what badge level?'). Also trigger proactively when creating new ChittyOS services, modifying wrangler configs, writing CHARTER/CHITTY/CLAUDE docs, checking canonical compliance, registration readiness, or preparing for deployment. +canon_uri: chittycanon://core/services/chittymarket#skills/chittyos-compliance +--- + +# ChittyOS Compatibility & Compliance + +Full lifecycle compliance management for the ChittyOS ecosystem: audit existing services, scaffold new ones, monitor deployed services, and certify artifacts. + +## Modes + +| Mode | Trigger | Purpose | +|------|---------|---------| +| **Audit** | "audit", "check compliance", "is this compliant?" | Full compliance check against ChittyOS standards | +| **Scaffold** | "scaffold", "new service", "generate templates" | Generate compliant CHARTER.md, CHITTY.md, health endpoint, wrangler config | +| **Monitor** | "monitor", "check health", "service status" | Hit deployed `*.chitty.cc/health` endpoints, verify live compliance | +| **Certify** | "certify", "certification", "ChittyCertify" | Evaluate artifacts against certification criteria, assign badge level | + +## Core Standards + +Every ChittyOS service MUST satisfy these requirements. + +### Required Files + +| File | Purpose | Frontmatter Required | +|------|---------|---------------------| +| `CHARTER.md` | Service charter — mission, scope, dependencies, API contract, ownership | Yes (type: policy) | +| `CHITTY.md` | Service badge & one-pager — identity, architecture, certification badges, ChittyDNA, ecosystem position. The service's "work badge" at a glance. | Yes (type: architecture) | +| `CLAUDE.md` | Developer guide — commands, dev workflow, patterns, gotchas | No | + +### Document Triad Coordination + +CHARTER.md, CHITTY.md, and CLAUDE.md form a coordinated triad — the charter (policy), the badge (identity), and the guide (developer docs). When auditing or creating these files, verify cross-document consistency: + +- **Tier** must match across CHARTER.md and CHITTY.md +- **Canonical URI** must be identical in both chartered docs +- **Domain** (`{name}.chitty.cc`) must be consistent across all three +- **Service name** in CLAUDE.md must match CHARTER.md classification +- **Dependencies** in CHARTER.md should appear in both CHITTY.md ecosystem section and CLAUDE.md architecture +- **API endpoints** in CHARTER.md contract must match CHITTY.md endpoints table and CLAUDE.md docs +- **Certification badge** in CHITTY.md must match `status` field in frontmatter +- **ChittyDNA** in CHITTY.md must reflect actual service lineage and identity +- **Tech stack** in CLAUDE.md must reflect actual implementation (not legacy references) + +When updating any one document, check the other two for consistency. When scaffolding, generate all three together to ensure alignment from the start. + +### Canonical YAML Frontmatter + +All chartered documents (CHARTER.md, CHITTY.md) require this metadata envelope. CHARTER.md uses `type: policy`, CHITTY.md uses `type: architecture`: + +```yaml +--- +uri: chittycanon://docs/{domain}/{type}/{identifier} +namespace: chittycanon://docs/{domain} +type: policy|spec|procedure|registry|architecture|catalog|summary +version: semver +status: DRAFT|PENDING|CERTIFIED|CANONICAL|DEPRECATED|ARCHIVED +registered_with: chittycanon://core/services/canon +title: string +certifier: chittycanon://core/services/chittycertify +visibility: PUBLIC|INTERNAL|CONFIDENTIAL|RESTRICTED +--- +``` + +Domains: `tech`, `legal`, `ops`, `exec`, `gov` + +### Service Identity + +- **Canonical URI**: `chittycanon://core/services/{service-name}` (kebab-case) +- **Domain**: `{service-name}.chitty.cc` or `{short-name}.chitty.cc` +- **Tier**: Must be consistent across CHARTER.md and CHITTY.md + +| Tier | Layer | Examples | +|------|-------|---------| +| 0 | Trust Anchors | ChittyID, ChittyTrust, ChittySchema | +| 1 | Core Identity | ChittyAuth, ChittyCert, ChittyRegister | +| 2 | Platform | ChittyConnect, ChittyRouter, ChittyAPI | +| 3 | Operational/Service | ChittyMonitor, ChittyFinance, ChittyLedger | +| 4 | Domain | ChittyEvidence, ChittyIntel, ChittyScore | +| 5 | Application | ChittyCases, ChittyPortal, ChittyDashboard | + +### Required Endpoints + +Every service MUST implement: +- `GET /health` returning `{"status":"ok","service":""}` +- `GET /api/v1/status` returning service metadata + +### Entity Type Ontology (P/L/T/E/A) + +All 5 types MUST be included in any entity type validation. Claude contexts are Person (P, Synthetic) — NEVER Thing (T). "Entity type" is the field name; "Entity" is NOT a valid type value. + +### Auth & Security + +- Standardize on `CHITTY_AUTH_SERVICE_TOKEN` (not `CHITTYCONNECT_API_TOKEN` or variants) +- Use `jose` library for JWT/JWKS on edge (not `jsonwebtoken`) +- CORS restricted to `*.chitty.cc` + localhost +- No hardcoded secrets in `[vars]` + +### Infrastructure + +- Worker name: `chitty*` convention +- `compatibility_date`: within 6 months of today +- `[[tail_consumers]]` with `service = "chittytrack"` for observability +- `package.json` name must match the service name + +--- + +## Ecosystem Discovery (Step 0 — ALL Modes) + +Before auditing, scaffolding, monitoring, or certifying ANY service, first discover its ecosystem context. Do NOT build or evaluate in a vacuum. + +### Discovery Steps + +1. **Query ChittyRegistry**: `curl -s https://registry.chitty.cc/api/services | jq .` — get the full service catalog +2. **Identify upstream/downstream services** — who does this service depend on? Who consumes it? +3. **Read the Compliance Triad** of related services — for each upstream and downstream dependency, read their `CHARTER.md` (API contract, endpoints), `CHITTY.md` (architecture, ecosystem position), and `CLAUDE.md` (dev patterns, integration examples) +4. **Check service repos** at: `/Volumes/chitty/github.com/CHITTYFOUNDATION/`, `/Volumes/chitty/github.com/CHITTYOS/`, `/Users/nb/desktop/projects/github.com/chittyapps` +5. **Local fallback**: `/Volumes/chitty/temp/systems-registry-import-v3.csv` + +### Why This Matters + +- Auditing requires knowing what correct integration looks like — read the dependency CHARTER.md contracts +- Scaffolding requires knowing what services to wire into — read peer CHITTY.md ecosystem sections +- Certifying requires knowing if dependencies are properly declared — cross-reference the registry +- Do NOT ask the user to list services — discover them yourself using these resources + +--- + +## Audit Mode + +Perform a comprehensive compliance check. + +### Audit Steps + +Run through the checklist directly: + +0. **Ecosystem Discovery** — Run Step 0 above to understand the service's place in the ecosystem +1. Check for required files (CHARTER.md, CHITTY.md, CLAUDE.md) +2. Validate frontmatter on chartered docs +3. Verify cross-document consistency (tier, URI, domain, endpoints) +4. Check canonical URI format +5. Verify health endpoint implementation +6. Scan for entity type violations +7. Check auth patterns and env var naming +8. Audit wrangler config +9. Verify package.json name +10. Check for `(c as any)` or other type-safety violations + +For detailed pass/fail criteria, consult **`references/compliance-checklist.md`**. + +### Deep Audit + +Dispatch specialized agents in parallel using `Task` with `run_in_background: true`: + +| Agent | Checks | +|-------|--------| +| `chittyagent-canon` | URI scheme, frontmatter, naming, ontology | +| `chittyagent-neon-schema` | Schema drift, cross-service compatibility | +| `chittyagent-register` | Registration readiness, payload validation | +| `chittyagent-connect` | Credentials, auth patterns, integrations | + +Perform the quick audit inline while agents run. Aggregate all findings into a unified report using the format in **`references/compliance-checklist.md`** (Audit Report Format section). + +--- + +## Scaffold Mode + +Generate compliant files for a new ChittyOS service. + +### Pre-Scaffold: Ecosystem Discovery + +Before scaffolding, run **Step 0 (Ecosystem Discovery)** to: +- Understand what tier this service belongs to and who its neighbors are +- Identify upstream dependencies by reading their CHARTER.md API contracts +- Identify downstream consumers by searching for services that reference this one +- Pre-populate the CHARTER.md dependencies section and CHITTY.md ecosystem section with real, verified integration points — not stubs + +### Scaffold Inputs + +Ask the user for: + +1. **Service name** (kebab-case) +2. **Tier** (0-5) +3. **Short description** (one sentence) +4. **Domain** (defaults to `{name}.chitty.cc`) +5. **Stack** (Hono + Workers is default) + +Generate files using templates from **`references/templates.md`**: CHARTER.md, CHITTY.md, health endpoint, wrangler config, and registration JSON. Populate dependency and integration sections from ecosystem discovery, not from guesswork. After scaffolding, run an audit to verify compliance. + +--- + +## Monitor Mode + +Check live deployed services. + +### Single Service +```bash +curl -s https://{service}.chitty.cc/health --max-time 5 | jq . +``` + +### Ecosystem Sweep +```bash +for svc in id auth connect api registry schema mcp finance command; do + echo -n "$svc: " + curl -s "https://$svc.chitty.cc/health" --max-time 5 | jq -r '.status // "DOWN"' +done +``` + +Compare deployed state against source: verify `/health` response format, check CHARTER.md tier consistency, verify wrangler compatibility date freshness. + +--- + +## Certify Mode (ChittyCertify) + +Evaluate any artifact against ChittyOS certification criteria and award badges. + +ChittyCertify operates like SOX/SOC II compliance auditing — it awards progressive **certifications** (NOT certificates; certificates are ChittyCert's domain). + +### Badge Progression + +``` +[No Badge] → ChittyOS Compatible → Chitty Compliant → ChittyCertified → ChittyCanonical +``` + +Each level is cumulative. For full badge criteria, certification process, and report format, consult **`references/certification-criteria.md`**. + +--- + +## Authority Model + +| Service | Role | What It Owns | +|---------|------|-------------| +| **ChittyGov** | Business governance & compliance | Required reports, state filings, regulatory compliance, business guidelines, legal requirements. Defines what "compliant" means. Approves Canonical status. | +| **ChittyCertify** | Compliance certification (like SOX/SOC II) | Audits services against compliance standards, awards certification badges (Compatible/Compliant/Certified/Canonical), issues compliance **certifications** + JWT attestation tokens. Certifications, NOT certificates. | +| **ChittyCert** | Certificate Authority (CA) | PKI infrastructure, X.509 **certificates**, OCSP revocation, JWKS key registry, evidence authentication. Certificates, NOT certifications. | +| **ChittyRegister** | Registration authority | Service onboarding, compliance gatekeeper, validates before ecosystem entry. Register, NOT registry. | +| **ChittyRegistry** | Discoverable service registry | Searchable catalog of all registered services, tools, scripts, agents, and artifacts. Services are discovered here. Registry, NOT register. | +| **ChittyCanon** | Canonical authority | Entity type ontology (P/L/T/E/A), URI namespace, code pattern governance | + +--- + +## Reference Files + +Consult these for detailed information: + +- **`references/compliance-checklist.md`** — Detailed pass/fail criteria for every compliance check, plus audit report format +- **`references/certification-criteria.md`** — Full badge award criteria, certification process, artifact types, and certification report format +- **`references/templates.md`** — Complete templates for scaffold mode (CHARTER.md, CHITTY.md, health endpoint, wrangler config, registration JSON, env types) + +## Integration with Other Skills + +| Skill | When to Chain | +|-------|--------------| +| `wrangler-audit` | After audit finds wrangler issues | +| `chitty-health` | During monitor mode for live checks | +| `chitty-deploy` | After scaffold + audit confirms compliance | +| `chitty-registry` | After certification to register the service | diff --git a/plugins/chittyos-devops/gemini-skills/wrangler-audit/SKILL.md b/plugins/chittyos-devops/gemini-skills/wrangler-audit/SKILL.md new file mode 100644 index 0000000..6226b5e --- /dev/null +++ b/plugins/chittyos-devops/gemini-skills/wrangler-audit/SKILL.md @@ -0,0 +1,155 @@ +--- +name: wrangler-audit +description: Audit all wrangler.toml files across CHITTYOS projects for consistency, stale compatibility dates, missing tail consumers, binding gaps, and route conflicts. Triggers on "wrangler audit", "audit workers", "check wrangler", "worker consistency", or /wrangler-audit. +canon_uri: chittycanon://core/services/chittymarket#skills/wrangler-audit +--- + +# Wrangler Audit + +Audit all Cloudflare Worker configurations across the ChittyOS ecosystem for consistency and correctness. + +## Procedure + +### Step 1: Discovery + +Find all wrangler.toml files in the workspace: + +```bash +find /Users/nb/Desktop/Projects/github.com/CHITTYOS -name "wrangler.toml" -not -path "*/node_modules/*" 2>/dev/null +``` + +Also check for wrangler.toml files inside nested worker directories: + +```bash +find /Users/nb/Desktop/Projects/github.com/CHITTYOS -name "wrangler.toml" -not -path "*/node_modules/*" -not -path "*/.wrangler/*" 2>/dev/null +``` + +### Step 2: Extract Config + +For each wrangler config file (`.toml`, `.json`, `.jsonc`), extract and compare: + +| Field | Check | +|-------|-------| +| `name` | Must match `chitty*` naming convention | +| `compatibility_date` | Flag if older than 6 months from today | +| `compatibility_flags` | Note any non-standard flags | +| `main` | Verify entry point file exists | +| `tail_consumers` | Every worker SHOULD have `service = "chittytrack"` | +| `observability.enabled` | MUST be `true` | +| `observability.logs.enabled` | MUST be `true` with `head_sampling_rate: 1` | +| `observability.logs.destinations` | MUST include `"chittytrack-logs"` / `"chittytrack-traces"` (the canonical OTLP logs sink at `track.chitty.cc/v1/logs`) | +| `observability.traces.enabled` | MUST be `true` | +| `observability.traces.destinations` | MUST include `"chittytrack-logs"` / `"chittytrack-traces"` (the canonical OTLP traces sink at `track.chitty.cc/v1/traces`) | +| `placement.mode` | SHOULD be `"smart"` for workers hitting Hyperdrive/Neon | +| `vars` | Check for hardcoded secrets (flag anything that looks like a token/key) | +| `kv_namespaces` | Cross-reference for duplicate binding names | +| `d1_databases` | Cross-reference for shared database names | +| `r2_buckets` | Cross-reference for shared bucket names | +| `env.production` / `env.staging` | Verify production and staging environments exist | +| `routes` / `*.chitty.cc` | Flag route conflicts between workers | + +### Step 3: Cross-Reference ChittyTrack (canonical observability sink) + +ChittyTrack (`track.chitty.cc`) is the centralized observability worker. Every production worker MUST emit telemetry to it via two mechanisms: + +**Mechanism A — Tail Consumer (legacy, low-detail):** +```toml +[[tail_consumers]] +service = "chittytrack" +``` + +**Mechanism B — Native OTLP Export (canonical, structured):** + +Required destinations (configured once in CF dashboard under Workers → Observability — destination names MUST be unique per destination): +- Destination name `chittytrack-traces` → URL `https://track.chitty.cc/v1/traces` (OTLP Traces Endpoint) +- Destination name `chittytrack-logs` → URL `https://track.chitty.cc/v1/logs` (OTLP Logs Endpoint) + +Required in every Worker's wrangler config: + +```jsonc +"observability": { + "enabled": true, + "logs": { + "enabled": true, + "head_sampling_rate": 1, + "invocation_logs": true, + "destinations": ["chittytrack-logs"] + }, + "traces": { + "enabled": true, + "head_sampling_rate": 1, + "destinations": ["chittytrack-traces"], + "persist": false + } +} +``` + +Or TOML equivalent: +```toml +[observability] +enabled = true + +[observability.logs] +enabled = true +head_sampling_rate = 1 +invocation_logs = true +destinations = ["chittytrack-logs"] + +[observability.traces] +enabled = true +head_sampling_rate = 1 +destinations = ["chittytrack-traces"] +persist = false +``` + +**Flag CRITICAL** for any worker that: +- Has `observability.enabled = false` or missing +- Has `observability.logs.destinations` missing `"chittytrack-logs"` / `"chittytrack-traces"` +- Has `observability.traces` block missing entirely +- Has `head_sampling_rate < 1` without justification (we want 100% during corpus-ingestion phase) + +**Flag WARNING** if `persist: true` for traces — this stores duplicates in CF dashboard AND forwards to chittytrack, wasting storage budget. + +**Note**: `tail_consumers = [{ service = "chittytrack" }]` is a legacy belt-and-suspenders mechanism. OTLP destinations are the canonical path. Both can coexist during transition. + +### Step 4: Compatibility Date Analysis + +Today's date determines staleness. Report: +- **Current** (< 3 months old): No action needed +- **Aging** (3-6 months old): Recommend update at next deploy +- **Stale** (> 6 months old): Flag for immediate update +- **Ancient** (> 12 months old): Critical — may miss important runtime changes + +### Step 5: Output Report + +```markdown +## Wrangler Audit Report + +### Summary +- Workers found: X +- Stale compatibility dates: X +- Missing tail consumers: X +- Route conflicts: X +- Issues found: X + +### Per-Worker Assessment + +| Worker | Compat Date | Age | Tail Consumer | Issues | +|--------|------------|-----|---------------|--------| +| ... | ... | ... | ... | ... | + +### Issues + +1. **[CRITICAL/WARNING/INFO]** description... + +### Recommended Actions + +1. ... +``` + +### Step 6: Optional Fix + +If the user asks to fix issues, update the wrangler.toml files: +- Update `compatibility_date` to today's date (YYYY-MM-DD) +- Add missing `[[tail_consumers]]` blocks +- Do NOT change routes, bindings, or environment configs without explicit confirmation diff --git a/plugins/chittyos-governance/gemini-skills/capability-governor/SKILL.md b/plugins/chittyos-governance/gemini-skills/capability-governor/SKILL.md new file mode 100644 index 0000000..f185732 --- /dev/null +++ b/plugins/chittyos-governance/gemini-skills/capability-governor/SKILL.md @@ -0,0 +1,86 @@ +--- +name: capability-governor +description: govern chittyos capability inventory, marketplace agents, skills, tools, plugins, mcp routes, and platform projections through an identity-first audit loop. use when asked to classify a capability, design or refactor a tool marketplace, deduplicate agents, decide whether something belongs as a skill/plugin/gateway/local integration/legal workflow, create a migration or retirement decision, audit system footprint, or enforce evidence-grade routing for legal, governance, valuation, custody, dispute, or forensic capabilities. +canon_uri: chittycanon://core/services/chittymarket#skills/capability-governor +--- + +# Capability Governor + +## Purpose + +Use this skill to run a repeatable capability-governance loop for ChittyOS-style ecosystems. The skill coordinates canonical identity, job-to-be-done taxonomy, system-footprint routing, evidentiary risk, platform projection, and artifact lifecycle decisions. + +Treat the marketplace as an identity-first, evidence-grade capability system, not a flat catalog of tools. Each capability should have one canonical identity and multiple controlled projections. + +## Core rule + +Always identify an existing canonical capability before creating a new one. Do not invent new schemas, databases, registries, or service boundaries. If source data is insufficient, return `hold` with the missing evidence. + +## Workflow + +1. Intake the artifact or inventory batch. +2. Search or inspect existing capability definitions, manifests, registries, skills, gateway routes, and legal/evidence workflows when available. +3. Assign a primary job-to-be-done. +4. Map the artifact to core entity anchors: person, location, thing/asset, event, action, or record. +5. Score environmental footprint. +6. Score evidentiary risk. +7. Decide canonical identity: keep, promote, project, merge, gateway, skill, local-only, legal-only, retire, or hold. +8. Produce the standard output package: taxonomy entry, disposition decision, decision log, and migration queue item. + +## Classification axes + +Use `references/decision-matrix.md` for placement decisions. +Use `references/projection-matrix.md` for runtime/channel exposure. +Use `references/output-templates.md` for standard output formats. +Use `references/runbook.md` for the full governance cycle. + +## Script usage + +For deterministic artifact classification, run: + +```bash +python scripts/audit_artifact.py --input artifact.json --pretty +``` + +For a batch file containing a JSON array of artifacts, run: + +```bash +python scripts/batch_audit.py --input artifacts.json --output audit-results.json +``` + +To validate a decision log, run: + +```bash +python scripts/validate_decision_log.py --input decision-log.json +``` + +## Disposition rules + +Assign exactly one primary disposition: + +- `keep`: valid existing canonical capability. +- `promote`: should become canonical after existing-first search. +- `project`: platform-specific projection of an existing canonical capability. +- `merge`: duplicate or overlapping artifact to consolidate. +- `gateway`: expose through search-and-execute or MCP gateway. +- `skill`: package as repeatable ChatGPT workflow, template, or operating procedure. +- `local-only`: requires filesystem, local state, privileged device access, or metadata preservation. +- `legal-only`: touches legal claims, evidence, custody, forensic state, valuation, disputes, filings, removal documents, or non-repudiable business records. +- `retire`: obsolete, unsafe, ownerless, superseded, or redundant. +- `hold`: insufficient evidence or unresolved canonical identity. + +## Non-repudiation gate + +Route any artifact touching legal, governance, valuation, removal documents, custody, disputes, forensic state, hashes, timestamps, or evidence records to `legal-only` unless the user explicitly provides an already-approved canonical legal/evidence route. Require source links, timestamp policy, hash policy, and decision log before activation. + +## Output standard + +Return: + +1. Capability taxonomy entry. +2. Disposition decision. +3. Decision log. +4. Migration queue item. +5. Missing evidence, if any. + +Keep summaries concise, but include enough source IDs, file links, repo references, or manifest names to make the decision auditable. diff --git a/plugins/chittyos-governance/gemini-skills/capability-registry-audit/SKILL.md b/plugins/chittyos-governance/gemini-skills/capability-registry-audit/SKILL.md new file mode 100644 index 0000000..efe5f8d --- /dev/null +++ b/plugins/chittyos-governance/gemini-skills/capability-registry-audit/SKILL.md @@ -0,0 +1,210 @@ +--- +name: capability-registry-audit +description: Audit a ChittyOS capability (tool, agent, skill, MCP server, plugin, manifest entry) against the canonical Capability Registry. Produces taxonomy entry, disposition decision, migration queue item, and decision log per the v0.2 runbook. Triggers on "audit capability", "classify capability", "registry audit", "is this a duplicate?", "/capability-registry-audit", or any new agent/tool/skill proposal. +canon_uri: chittycanon://core/services/chittymarket#skills/capability-registry-audit +--- + +# Capability Registry Audit + +Runs the canonical audit process from `docs/capability-registry-audit-runbook.md` v0.2 on a single capability or a batch. Identity-first, evidence-grade. Never create a new canonical entry until existing inventory is searched. + +**Reference:** the runbook is the spec. This skill is the executable workflow. + +## When to invoke + +- New tool / agent / skill / MCP server / plugin proposed +- Suspected duplicate +- New platform adapter or projection added +- Marketplace cleanup pass +- Any artifact touching legal / evidence / custody / governance +- Monthly governance cycle + +## Inputs + +Collect from the user (ask only what is missing — do not bounce trivially-derivable items): + +```yaml +capability_name: # current user-facing name +source_link: # repo path, manifest entry, MCP endpoint, doc URL +current_runtime: # ChatGPT | Claude Code | MCP | CLI | web | legal-space | other +primary_job: # one sentence — what is the user accomplishing? +data_touched: # files, records, entities, assets, logs, financials +privilege_level: # none | read-only | write | filesystem | network | admin | forensic +evidence_impact: # none | low | medium | high | legal-grade +requested_action: # classify | add | merge | retire | migrate | expose +``` + +## Procedure + +### Step 1 — Existing-first search (MANDATORY) + +Before classifying anything, search the existing canonical inventory. Do all five in parallel: + +1. **Canonical overlay (primary)** — `jq '.capabilities[] | select(.name | test(""; "i") or .description | test(""; "i"))' capabilities.generated.json`. This is the canonical Capability Record source as of Phase 1 (102 capabilities). Each record carries `capability_id` (chittycanon URI), `capability_group`, `execution_class`, `ontology` (P/L/T/E/A), `canonical_version`, and `discovery` rules. +2. `curl -s https://registry.chitty.cc/api/services | jq '.services[] | select(.name | test(""; "i"))'` +3. Grep `marketplace.json` and `.claude-plugin/marketplace.json` for related names. +4. Read related CHARTER.md / CHITTY.md / CLAUDE.md for closest canonical capability. +5. Check Ch1tty `servers.json` and ChittyMCP tool list for live registrations. + +The overlay is generated; if your audit produces a disposition that would change a record, the upstream generator must be re-run — do not hand-edit `capabilities.generated.json`. See `docs/architecture/CHITTYMARKET_CAPABILITY_ROUTER.md`. + +**Gate:** if a canonical capability already exists with overlapping job-to-be-done, the new artifact is a **projection / adapter / duplicate candidate**, not a new root. Stop and route to Step 5 with `merge` or `project` disposition. + +### Step 2 — Classify across the 5 axes + +Apply the runbook taxonomy: + +- **A. Job-to-be-done**: verify | collect | route | generate | govern | operate | resolve | remember +- **B. Environmental footprint**: context-only | read-only | write-capable | filesystem-local | network-service | admin-system | forensic-legal-grade +- **C. Evidentiary risk**: none | low | medium | high | legal-grade +- **D. Runtime projection**: skill | mcp-tool | local-cli | gateway-search-execute | web-portal | legal-space-only | retired +- **E. Entity mapping (P/L/T/E/A)**: at least one of Person / Location / Thing / Event / Authority — `chittycanon://gov/governance#core-types` + +A capability with **no entity mapping is a smell** → disposition `hold` until re-audited. + +### Step 3 — Capability Placement Decision Matrix + +Walk top-to-bottom. First "Yes" wins: + +1. Already exists under another name? → **Merge / Project** +2. Only a platform adapter for existing capability? → **Project** +3. Genuinely new job-to-be-done? → **Promote / Keep** +4. Only needs reasoning / templates / repeatable procedure? → **Skill** +5. Needs API/tool execution? → **MCP / Gateway** +6. Many tools, only some per task? → **Search-and-Execute Gateway** +7. Needs filesystem / device state / metadata preservation? → **Local-Only** +8. Touches live memory / bit-stream / hashes / custody / forensic state? → **Legal / Evidence Pipeline** +9. Touches governance / valuation / removal docs / claims / filings / disputes? → **Legal Space + Non-Repudiation Gate** +10. Obsolete / redundant / unsafe / ownerless? → **Retire** + +### Step 4 — Apply governance gates + +- **Non-repudiation gate** — any legal / governance / valuation / custody / forensic capability must carry hash + timestamp + source trail before activation. If missing, block with `hold`. +- **Per-channel projection allow/deny** — emit `allowed_projections` and `restricted_projections`. The compiler must refuse projections into channels not on the allow list. See runbook §12. +- **Sensitive intent routing** — anything touching credentials / secrets / deploy / registry mutation routes through `ch1tty → ChittyConnect`. Fail closed with `POLICY_BLOCKED_CHITTYCONNECT_UNAVAILABLE` if broker unavailable. + +### Step 5 — Emit the four standard outputs + +Produce all four. Do not skip any. + +#### Output 1 — Taxonomy entry + +```yaml +canonical_id: # stable kebab-case ID +display_name: +job_to_be_done: +entity_mapping: [P|L|T|E|A] +source_of_truth: # canonical repo + path +environmental_footprint: +evidentiary_risk: +canonical_version: # semver — projections inherit, never fork +runtime_exclusions: [] # e.g. [openclaw] for security-restricted runtimes +allowed_projections: [] +restricted_projections: [] +non_repudiation_required: false +slim_mcp_hint: # one-line cheat-sheet entry for the SessionStart index +owner: +status: active | experimental | deprecated +``` + +#### Output 2 — Disposition decision + +Exactly one of: `keep | promote | project | merge | gateway | skill | local-only | legal-only | retire | hold` + +```yaml +decision_id: +date: +capability_name: +canonical_id: +decision: +rationale: # why this disposition, citing the matrix step that triggered it +duplicates_found: [] +migration_required: yes | no +next_action: +review_date: +``` + +#### Output 3 — Migration queue item (only if `migration_required: yes`) + +```yaml +migration_item: +from_artifact: +to_canonical_capability: +action: merge | rename | reroute | retire | document | restrict +blocking_dependencies: [] +risk_level: low | medium | high +owner: +status: backlog +completion_evidence: # link to PR / commit / deploy that closes it +``` + +#### Output 4 — Decision log entry + +Append to `docs/decisions/capability-audit-log.md` (create if missing). One entry per audit. + +```yaml +decision_id: +date: +capability_name: +canonical_id: +source_links: [] +current_state: +decision: +job_to_be_done: +entity_mapping: [P|L|T|E|A] +environmental_footprint: +evidentiary_risk: +rationale: +duplicates_found: [] +migration_required: yes | no +migration_owner: +next_action: +review_date: +``` + +### Step 6 — Quality gates (block on failure) + +The audit is not complete unless: + +- [ ] Existing inventory was searched first. +- [ ] Exactly one primary job-to-be-done. +- [ ] At least one P/L/T/E/A entity mapping. +- [ ] Exactly one disposition. +- [ ] Evidence-touching items routed to Legal space. +- [ ] High-privilege items not broadly exposed. +- [ ] Platform variants tied to one canonical identity. +- [ ] Dual-manifest drift checked (canonical vs projection manifests). +- [ ] Non-repudiation gate applied where required. +- [ ] Retirement decisions include a replacement or rollback path. +- [ ] Decision log includes source links. + +## Reporting + +Return a single markdown report containing: + +1. Capability under audit (1-line summary). +2. Existing-first search results (what was found, what wasn't). +3. Classification across all 5 axes. +4. Matrix walk: which question triggered the disposition. +5. The four standard outputs (above). +6. Quality-gate checklist with pass/fail per item. + +## Batch mode + +When auditing inventory (e.g., `marketplace.json`), prioritize in this order: + +1. Obvious duplicates +2. Legal / evidence tools +3. High-privilege local tools +4. Gateway candidates +5. Stale marketplace entries + +Cap each batch at 10–20 artifacts; produce one consolidated report with a per-item disposition table plus per-item full outputs in an appendix. + +## Anti-patterns (refuse to produce) + +- Creating a new canonical ID without an existing-first search. +- Emitting a disposition with no entity mapping. +- Promoting a platform-specific clone to canonical when an upstream capability already exists. +- Approving a legal/evidence capability without the non-repudiation gate. +- Allowing a projection into a channel not on the canonical `allowed_projections` list. diff --git a/plugins/chittyos-legal/gemini-skills/dispute/SKILL.md b/plugins/chittyos-legal/gemini-skills/dispute/SKILL.md new file mode 100644 index 0000000..a5d24f8 --- /dev/null +++ b/plugins/chittyos-legal/gemini-skills/dispute/SKILL.md @@ -0,0 +1,198 @@ +--- +name: dispute +description: 'Issue and dispute management for property, insurance, legal, and financial matters. Triggers on: "dispute", "issue", "claim", "damage", "leak", "create dispute", "list disputes", "dispute status", "water damage", "insurance claim", "property issue", "vendor dispute", "tenant complaint". Creates, tracks, and resolves multi-domain disputes via the ChittyDisputes API.' +canon_uri: chittycanon://core/services/chittymarket#skills/dispute +--- + +# Dispute — Issue/Dispute Management + +## Overview + +Manages multi-domain disputes that can span property management, insurance, legal, financial, and vendor domains simultaneously. A single issue (e.g., water leak at Addison) can touch property damage, insurance claims, vendor remediation, tenant communication, and legal liability all at once. + +## API Configuration + +| Field | Value | +|-------|-------| +| **Service** | ChittyDisputes | +| **Base URL** | `https://disputes.chitty.cc` | +| **Health** | `GET /health` | +| **Database** | Neon PostgreSQL (ChittyLedger), schema: public | + +## Dispute Types + +| Type | When to Use | +|------|-------------| +| `PROPERTY` | Physical property damage, maintenance, repairs | +| `INSURANCE` | Insurance claims, coverage disputes, adjuster interactions | +| `LEGAL` | Liability, breach of contract, negligence claims | +| `FINANCIAL` | Billing disputes, payment issues, cost overruns | +| `TENANT` | Tenant complaints, lease violations, move-out disputes | +| `VENDOR` | Contractor/vendor quality, timeline, payment disputes | +| `HOA` | HOA violations, special assessments, board disputes | +| `REGULATORY` | Code violations, permit issues, compliance failures | + +## Severity Levels + +| Level | Criteria | +|-------|----------| +| `CRITICAL` | Active damage, safety hazard, imminent deadline | +| `HIGH` | Approaching deadline, significant financial exposure | +| `MEDIUM` | Standard priority, no immediate deadline pressure | +| `LOW` | Informational, monitoring only | + +## Status Lifecycle + +``` +INTAKE → OPEN → INVESTIGATING → PENDING → ESCALATED → RESOLVED + ↓ ↓ + CLOSED CLOSED +``` + +## API Endpoints + +### Create Dispute +```bash +curl -X POST https://disputes.chitty.cc/api/disputes \ + -H "Content-Type: application/json" \ + -d '{ + "title": "Water leak at 541 W Addison #3S", + "description": "Upstairs unit water damage to kitchen ceiling...", + "dispute_type": "PROPERTY", + "severity": "HIGH", + "domains": ["PROPERTY", "INSURANCE", "VENDOR"], + "property_address": "541 W Addison St", + "property_unit": "3S", + "reported_by": "nick@aribia.cc", + "estimated_cost": 5000, + "next_action_date": "2026-02-25T00:00:00Z", + "next_action_description": "Get remediation estimate from ServiceMaster", + "tags": ["water-damage", "addison"] + }' +``` + +### List Disputes +```bash +# All open disputes +curl "https://disputes.chitty.cc/api/disputes?status=OPEN" + +# Property disputes +curl "https://disputes.chitty.cc/api/disputes?type=PROPERTY" + +# By severity +curl "https://disputes.chitty.cc/api/disputes?severity=HIGH" + +# By property +curl "https://disputes.chitty.cc/api/disputes?property=Addison" +``` + +### Get Dispute with Timeline +```bash +curl "https://disputes.chitty.cc/api/disputes/{id}" +``` + +### Update Dispute +```bash +curl -X PATCH "https://disputes.chitty.cc/api/disputes/{id}" \ + -H "Content-Type: application/json" \ + -d '{ + "status": "INVESTIGATING", + "assigned_to": "nick@aribia.cc", + "next_action_date": "2026-02-28T00:00:00Z", + "next_action_description": "Follow up with State Farm adjuster", + "updated_by": "claude-session" + }' +``` + +### Add Timeline Event +```bash +curl -X POST "https://disputes.chitty.cc/api/disputes/{id}/events" \ + -H "Content-Type: application/json" \ + -d '{ + "event_type": "phone_call", + "summary": "Called State Farm, claim #SF-2026-12345 opened", + "details": {"claim_number": "SF-2026-12345", "adjuster": "Jane Smith"}, + "actor": "nick" + }' +``` + +### Dashboard Summary +```bash +curl "https://disputes.chitty.cc/api/disputes/summary" +``` + +## Workflows + +### Creating a New Dispute + +When the user reports an issue: + +1. **Identify the dispute type and domains** — A water leak is `PROPERTY` type but domains might include `['PROPERTY', 'INSURANCE', 'VENDOR']` +2. **Set severity** based on urgency — active damage = `CRITICAL`, deadline approaching = `HIGH` +3. **Create the dispute** via API with all known details +4. **Set next action** — what needs to happen next and by when +5. **Report back** the dispute ID and summary + +### Updating an Existing Dispute + +1. **List or search** for the dispute +2. **Add timeline events** for any actions taken (calls, emails, documents received) +3. **Update status** as the dispute progresses through the lifecycle +4. **Link documents** by adding to `document_refs` array +5. **Track costs** — update `estimated_cost` and `actual_cost` as quotes come in + +### Resolving a Dispute + +1. **Set resolution_type** — what resolved it (e.g., "repaired", "settled", "insured") +2. **Add resolution_notes** — summary of resolution +3. **Set status to RESOLVED** +4. **Log final costs** in `actual_cost` + +## Domains Array + +A dispute's `domains` array tracks which areas it touches. This is key for the Addison water leak example: + +```json +{ + "domains": ["PROPERTY", "INSURANCE", "VENDOR"], + "explanation": "Property damage needs repair (PROPERTY), insurance claim filed (INSURANCE), remediation vendor hired (VENDOR)" +} +``` + +As the dispute evolves, domains can be added: +- Tenant complains → add `TENANT` +- Liability question arises → add `LEGAL` +- HOA gets involved → add `HOA` + +## Event Types + +| Type | When | +|------|------| +| `created` | Dispute first created (auto) | +| `status_change` | Status transitions (auto-logged by trigger) | +| `note` | General notes, observations | +| `document_added` | Document attached or referenced | +| `email_received` | Relevant email received | +| `email_sent` | Email sent regarding dispute | +| `phone_call` | Phone call made/received | +| `assignment` | Dispute assigned to someone | +| `escalation` | Escalated to attorney or higher | +| `deadline_set` | New deadline established | +| `cost_update` | Cost estimate or actual cost changed | +| `resolution` | Resolution details recorded | + +## Notion Sync + +Disputes can be synced to Notion for human visibility. Use the Notion MCP tools to: + +1. Create a row in the disputes database with key fields +2. Update the row when status changes +3. Add timeline events as comments or sub-pages + +## Important Rules + +- **Always set `next_action_date` and `next_action_description`** — disputes without next actions go stale +- **Log every interaction as a timeline event** — phone calls, emails, document receipts +- **Use domains array** to track which areas a dispute touches — this is how we route and prioritize +- **Set deadlines** — response_deadline for when we must respond, resolution_deadline for target resolution +- **Track costs** — estimated_cost when first assessed, actual_cost when invoices arrive diff --git a/plugins/chittyos-legal/gemini-skills/docket/SKILL.md b/plugins/chittyos-legal/gemini-skills/docket/SKILL.md new file mode 100644 index 0000000..803111b --- /dev/null +++ b/plugins/chittyos-legal/gemini-skills/docket/SKILL.md @@ -0,0 +1,186 @@ +--- +name: docket +description: Pull, view, and update Cook County Circuit Court docket for a specified case. Triggers on "docket", "court date", "next hearing", "case status", "pull docket", "court activity". REQUIRES an explicit case parameter (case number or registry slug) — refuses to run without one. Scrapes live docket via browser automation, updates the master timeline CSV, and syncs to ChittyLedger. +canon_uri: chittycanon://core/services/chittymarket#skills/docket +--- + +# Docket — Cook County Case Tracker + +## Required: `case` parameter + +This skill **requires** an explicit case identifier on every invocation. It MUST NOT default to any particular case. Accept either: + +- **`case_number`** — the Cook County case number (e.g. `2024D007847`) +- **`case_slug`** — a registered case slug (e.g. `arias-v-bianchi`); resolve through the chittyrouter case registry or chittyevidence-db `evidence_cases` table + +If the invocation does not specify a case, stop and ask the caller for one. Do not guess. + +## Case Configuration Schema + +For each case, expect the following configuration shape (populate from the case registry, not from skill defaults): + +| Field | Required | Source | +|-------|----------|--------| +| `caseNumber` | yes | invocation parameter | +| `division` | yes | case registry (e.g. "Domestic Relations" = value 4) | +| `calendar` | yes | case registry | +| `court` | yes | "Circuit Court of Cook County, Illinois" | +| `room` | no | case registry | +| `judge` | no | case registry | +| `plaintiff` / `defendant` | no | case registry | +| `url` | constant | `https://casesearch.cookcountyclerkofcourt.org/CivilCaseSearchAPI.aspx` | + +### Worked Example: Arias v. Bianchi + +Only as an illustration of the shape — do NOT use this as a default: + +| Field | Value | +|-------|-------| +| `caseNumber` | `2024D007847` | +| `division` | Domestic Relations (value=4) | +| `calendar` | DRCAL23 | +| `court` | Circuit Court of Cook County, Illinois | +| `room` | 2108, Richard J Daley Center | +| `judge` | Johnson, Robert W. | + +## Data Stores (per case) + +All paths MUST be scoped by case slug. Never share a master timeline CSV across cases. + +| Store | Location pattern | Format | +|-------|------------------|--------| +| **Master Timeline** | `//Master_Timeline.csv` | CSV | +| **Notion Evidence** | `/ChittyLedger/CL - Evidence//` | Markdown files per entry | +| **Case Checkpoints** | `~/.claude/chittycontext/checkpoints//` | JSON | +| **Notion Projects DB** | `999c414c-06c5-4064-a51b-921193830968` | Notion API (case filtered by `case_slug`) | +| **Notion Actions DB** | `6b52d580-f810-4009-964d-478039c144e1` | Notion API (case filtered by `case_slug`) | + +## Commands + +All commands below require `case=`. Examples use `case=` as a placeholder. + +### `/docket pull case=` +Pull the full live docket from Cook County Clerk website for the specified case. + +### `/docket new case=` +Pull only entries newer than the last entry in that case's master timeline CSV. + +### `/docket next case=` +Show the next scheduled court date for the specified case. + +### `/docket summary case=` +Show a summary of recent activity (last 30 days) and next court date for the specified case. + +### `/docket update case=` +Pull live docket and update that case's master timeline CSV with new entries. + +## Workflow: Pull Live Docket + +### Step 1: Resolve the case +1. Read `case` parameter from invocation. +2. Resolve against the case registry (chittyrouter `CASE_BY_NUMBER` / `CASE_BY_SLUG` or chittyevidence-db `evidence_cases`). +3. If not found: stop, report "unknown case" to caller. Do not fall back. + +### Step 2: Load Browser Tools +``` +ToolSearch: select:mcp__claude-in-chrome__tabs_context_mcp +ToolSearch: select:mcp__claude-in-chrome__tabs_create_mcp +ToolSearch: select:mcp__claude-in-chrome__navigate +ToolSearch: select:mcp__claude-in-chrome__read_page +ToolSearch: select:mcp__claude-in-chrome__computer +ToolSearch: select:mcp__claude-in-chrome__javascript_tool +``` + +### Step 3: Navigate to Case Search +1. Get tab context: `mcp__claude-in-chrome__tabs_context_mcp` (createIfEmpty: true) +2. Create new tab: `mcp__claude-in-chrome__tabs_create_mcp` +3. Navigate to: `https://casesearch.cookcountyclerkofcourt.org/CivilCaseSearchAPI.aspx` + +### Step 4: Search for Case +The site is ASP.NET WebForms. **Do NOT use JavaScript to set form values** — they get cleared on postback. Use direct interaction: + +1. **Select Division** per the resolved case (e.g. "Domestic Relations / Child Support" = value "4") +2. **Ensure "Search by Case Number" radio** is selected (first radio button) +3. **Click into the case number text input** (triple_click to select any existing text) +4. **Type case number**: Use `computer` type action with `` from the resolved case (e.g. `2024D007847` for arias-v-bianchi) +5. **Click "Start New Search"** button (type="submit") +6. **Wait 3-4 seconds** for page load + +### Step 5: Read Docket Results +Use `read_page` with: +- `filter: "all"` +- `depth: 10` +- `max_chars: 80000` + +The page structure returns: +- **Case header**: Case number, calendar, date filed, division +- **Parties**: Plaintiff, Defendant, Attorney, Case Type +- **Future Court Activity**: Next hearing date, type, time, location +- **Case Activities**: Reverse-chronological list of all docket entries + +Each activity entry is structured as: +``` +Activity Date: MM/DD/YYYY +Event Desc: [description] +Comments: [optional comments] +``` + +### Step 6: Parse Results +Extract from the accessibility tree: +1. **Next court date** from "Future Court Activity" section +2. **All case activities** with date, event description, and comments +3. Compare against the case's master timeline CSV to identify NEW entries + +### Step 7: Update Master Timeline (if `/docket update`) +**CSV Format** (7 columns): +```csv +Date,Event,Entity,Document Title,Description,Evidence Source (file),Link +``` + +**Mapping from docket to CSV:** +| Docket Field | CSV Column | +|-------------|------------| +| Activity Date (reformatted YYYY-MM-DD) | Date | +| Event Desc | Event | +| "Cook County Circuit Court" | Entity | +| "Cook County online docket" | Document Title | +| Comments (or Event Desc if no comments) | Description | +| `"Docket: "` (from resolved case) | Evidence Source | +| (empty) | Link | + +**Append** new entries to the CSV in chronological order. Do NOT duplicate existing entries. + +### Step 8: Report +Output a formatted summary: + +```markdown +## Docket Pull — — [Date] + +**Next Court Date:** [date] at [time] — [type] — Room [room] + +### New Entries Since Last Pull +| Date | Event | Comments | +|------|-------|----------| +| ... | ... | ... | + +### Docket Totals +- Total entries: [N] +- New since last pull: [N] +- Master timeline updated: [yes/no] +``` + +## Validation Rules + +1. **Date format**: Docket returns MM/DD/YYYY — convert to YYYY-MM-DD for CSV +2. **Deduplication**: Match on (date + event description) — skip if already in CSV +3. **Future dates**: Mark as "(FUTURE)" in the Event column when adding to CSV +4. **Comments with commas**: Wrap in double quotes in CSV +5. **Special characters**: Escape quotes in CSV fields +6. **Case scope**: Never write docket entries from case A into case B's master timeline. Validate on write that `Evidence Source` contains the expected `caseNumber`. + +## Invocation Rejection + +If invoked without a `case` parameter, the skill MUST: +1. Refuse to proceed. +2. Return a message: "docket: no `case` specified — refusing to run. Provide `case=` or `case_number=`." +3. List currently registered cases (from the registry) so the caller can pick one. diff --git a/plugins/chittyos-legal/gemini-skills/evidence-collect/SKILL.md b/plugins/chittyos-legal/gemini-skills/evidence-collect/SKILL.md new file mode 100644 index 0000000..24083a9 --- /dev/null +++ b/plugins/chittyos-legal/gemini-skills/evidence-collect/SKILL.md @@ -0,0 +1,221 @@ +--- +name: evidence-collect +description: 'Evidence collection and ingestion for a specified case. REQUIRES an explicit `case` parameter — refuses to run without one. Triggers on: downloading evidence, staging documents, collecting exhibits, pulling files from Google Drive, ALTA statements, closing disclosures, deeds, wire receipts, purchase contracts, mortgage documents, financial records, or any file retrieval for litigation purposes. Prevents ad-hoc file copying by enforcing the canonical pipeline.' +canon_uri: chittycanon://core/services/chittymarket#skills/evidence-collect +--- + +# Evidence Collection — Canonical Pipeline + +## Required: `case` parameter + +This skill **requires** an explicit case identifier on every invocation. It MUST NOT default to any previously-used case. + +Accept either: + +- **`case_id`** — the chittyevidence-db case identifier (e.g. `arias-v-bianchi-2024d007847`) +- **`case_slug`** — a registered case slug (e.g. `arias-v-bianchi`, `clarendon-1610`, `fox-hoa`); resolve via `evidence_cases` or the chittyrouter case registry + +If no `case` is specified, stop and ask the caller for one. Do not fall back to "the last case we worked on" or any hardcoded default. + +Every bucket path, local path, and SQL example below uses `` or `` as a placeholder — substitute the resolved case at runtime. Do not paste literals. + +## STOP. READ THIS FIRST. + +**DO NOT manually copy, download, or stage evidence files.** There is already a full pipeline. Use it. + +The #1 failure mode is creating yet another copy of documents that already exist in 6+ locations. Every manual `cp` or `rclone copy` to a random directory creates evidence sprawl and breaks chain of custody. + +The #2 failure mode — historically observed — is attributing a document from case A to case B because the pipeline was run with a stale or hardcoded case default. Always re-resolve the case at invocation. + +## Pre-Flight Checklist + +Before downloading or staging ANY document, with the resolved case in hand: + +1. **Check R2 first** — the document is probably already ingested for THIS case +2. **Check the Neon DB** — the fact may already be registered (scoped to `case_id = `) +3. **If it's not in R2 for this case** — use the pipeline, not manual copies +4. **If you need a fact** — query the DB (scoped by `case_id`), don't re-extract from source +5. **Reject cross-case leaks** — if you find the doc only in a DIFFERENT case's folder, do NOT silently copy it over. Ask the caller whether the doc legitimately belongs to the new case. + +## Architecture + +``` +Source (Drive remote for ) Local Files + │ │ + └──────────┬─────────────────────────┘ + │ + ▼ + ┌──────────────┐ + │ 00_inbox/ │ ← ALL documents for THIS case land here first + └──────┬───────┘ + │ bin/intake.py --case= + ▼ + ┌──────────────┐ + │ Case Folders │ ← Routed by keyword matching, scoped to case + │ (02-10) │ + └──────┬───────┘ + │ bin/r2_import.py --case= + ▼ + ┌─────────────────────┐ + │ R2 Buckets │ + │ quarantine → staging → signed │ + │ (all case-prefixed) │ + └──────────┬──────────┘ + │ ChittyEvidence Worker + ▼ + ┌─────────────────────┐ + │ Neon PostgreSQL │ + │ verification.* │ + │ evidence_statement_of_facts (scoped to case_id) │ + └──────────┬──────────┘ + │ Notion sync (case's workspace) + ▼ + ┌─────────────────────┐ + │ Notion Facts Table │ + │ (case-specific) │ + └─────────────────────┘ +``` + +## R2 Buckets (Source of Truth) + +Case documents live under a case-prefixed key within each bucket (e.g. `CASE_/` or `/`). Never write to the bucket root without a case prefix. + +| Bucket | Purpose | Status | +|--------|---------|--------| +| `chittyevidence-documents` | Canonical document store (staging/) | Active | +| `chittyevidence-pipeline` | Pipeline manifests & collections | Active | +| `chittyevidence-processed` | Post-processing output | Active | +| `legal-evidence-quarantine` | Incoming, unverified | Active | +| `legal-evidence-staging` | Processing in progress | Active | +| `legal-evidence-signed` | Verified + deduplicated | Active | +| `legal-evidence-originals` | Pristine originals | Active | +| `legal-evidence-working` | Scratch space | Active | + +## Step 1: Check If Document Already Exists + +```bash +# Search R2 for the document, scoped to the case +rclone ls r2:chittyevidence-documents// --include "*keyword*" 2>&1 +rclone ls r2:legal-evidence-signed// --include "*keyword*" 2>&1 + +# Check duplicates quarantine within this case +rclone ls r2:legal-evidence-signed//00_ADMIN/duplicates_quarantine/ --include "*keyword*" 2>&1 +``` + +If found in this case's prefix → **STOP**. Use the existing copy. +If found in ANOTHER case's prefix → **STOP and ask the caller** whether it legitimately belongs here. Do not copy automatically. + +## Step 2: Check If Fact Already Registered + +Use the fact-governance skill to query Neon (always with `case_id = ?`): + +```sql +SELECT id, fact_number, fact_text, exhibit_reference, status, category +FROM evidence_statement_of_facts +WHERE case_id = ? -- resolved + AND (fact_text ILIKE '%keyword%' OR exhibit_reference ILIKE '%keyword%') + AND status NOT IN ('archived', 'rejected') +ORDER BY fact_number; +``` + +If found → **STOP**. The fact is already in the system. Do not re-extract. + +## Step 3: Ingest New Documents (If Genuinely New) + +Pipelines pass the case slug/id into each script. Example paths below use `` and `` placeholders — each case has its own drive remote name (e.g. `arias_v_bianchi:`, `clarendon_1610:`, `fox_hoa:`). + +### Option A: From Drive → 00_inbox → intake.py + +```bash +cd "/" +rclone copy ":path/to/file.pdf" 00_inbox/ +python3 bin/intake.py --case= +``` + +### Option B: From R2 → 00_inbox → intake.py + +```bash +cd "/" +python3 bin/r2_import.py --case= --prefix '' --pattern '*.pdf' --recursive --dest 00_inbox +python3 bin/intake.py --case= +``` + +### Option C: Bulk from Drive URL list + +```bash +cd "/" +python3 bin/rclone_import.py --case= --remote --list google_drive_urls.txt +python3 bin/intake.py --case= +``` + +## Step 4: Register Facts + +After documents are properly staged, use the fact-governance skill (which also requires `case` parameter) to register extracted facts. Every INSERT must bind the resolved `case_id`: + +```sql +INSERT INTO evidence_statement_of_facts ( + id, case_id, fact_number, fact_date, fact_text, + exhibit_reference, source_quote, status, version, category, + submitted_by, created_at, updated_at +) VALUES ( + 'FACT-' || hex(randomblob(8)), + ?, -- — resolved at invocation + (SELECT COALESCE(MAX(fact_number), 0) + 1 FROM evidence_statement_of_facts WHERE case_id = ?), + ?, ?, ?, ?, 'draft', 1, ?, + 'claude-evidence-collect', + datetime('now'), datetime('now') +); +``` + +## rclone Remotes Reference + +Each case has its own drive remote. Add new cases to the case registry; never hardcode a remote here. + +| Remote pattern | Access | Use For | +|----------------|--------|---------| +| `:` (Drive) | Google Drive shared | Source documents for that case | +| `r2:` | Cloudflare R2 | Canonical evidence store (all cases, case-prefixed keys) | +| `sd_:` (if applicable) | SD card archive | Offline backup per case | + +## Case Directory Layout + +Each case lives under its own slug-rooted directory: + +``` +// +├── 00_inbox/ ← ALL incoming docs for THIS case land here +├── bin/ +│ ├── intake.py ← Routes inbox → case folders (case-aware) +│ ├── r2_import.py ← Pulls from R2 (case-prefixed) +│ └── rclone_import.py ← Pulls from Google Drive (case-specific remote) +├── 06_evidence/ +│ ├── EVIDENCE_LOG.md +│ └── documents/ ← Only populated by intake.py +└── 07_exhibits/ + └── EXHIBIT_LIST.md +``` + +Never co-mingle files across case directories. If you discover a document apparently in the wrong case directory, halt and escalate — do not silently move. + +## Anti-Patterns (Things That MUST NOT Happen) + +1. **DO NOT** invoke this skill without a `case` parameter. +2. **DO NOT** `rclone copy` directly to `06_evidence/documents/` — use `00_inbox/` + `intake.py`. +3. **DO NOT** download the same document from multiple aggregation folders. +4. **DO NOT** create facts without `exhibit_reference`. +5. **DO NOT** state a date, amount, or fact that isn't in the source document — say "I don't have that". +6. **DO NOT** manually write EVIDENCE_LOG.md entries — `intake.py` handles this. +7. **DO NOT** write a document from case A into case B's evidence store. Cross-case contamination is the exact class of bug this skill must prevent. + +## Case-Specific Evidence Data + +Evidence data (verified property details, dates, amounts, party names, per-case aggregations) belongs in the case's evidence DB, NOT in this skill doc. Query `evidence_statement_of_facts` scoped to `case_id = ?` to retrieve verified facts for the resolved case. + +Historical note: an earlier version of this skill embedded concrete Arias v. Bianchi property data and marriage date directly in the doc. That content has been removed — it lives in the `evidence_statement_of_facts` table, correctly scoped to `case_id = 'arias-v-bianchi-2024d007847'`, and should be queried per invocation. + +## Invocation Rejection + +If invoked without a `case` parameter, the skill MUST: +1. Refuse to proceed. +2. Return: "evidence-collect: no `case` specified — refusing to run. Provide `case_id=` or `case_slug=`." +3. List the caller's currently-active cases so they can pick one. diff --git a/plugins/chittyos-legal/gemini-skills/evidence-egress/SKILL.md b/plugins/chittyos-legal/gemini-skills/evidence-egress/SKILL.md new file mode 100644 index 0000000..0dd1eb6 --- /dev/null +++ b/plugins/chittyos-legal/gemini-skills/evidence-egress/SKILL.md @@ -0,0 +1,115 @@ +--- +name: evidence-egress +description: 'Migrate evidence/document files out of scattered local source directories (Desktop, iCloud, Downloads, external) into the canonical pipeline (R2 + Drive mirror + local working copy). Read-only audit by default — produces per-case CSV reports of {in_neon, in_drive, action_needed} before any move or delete. Case-agnostic: discovers cases from /cases/* and resolves Drive remotes by convention (sd_:). Triggers on: ''egress'', ''evidence egress'', ''migrate evidence'', ''free up desktop'', ''iCloud evidence sprawl'', ''audit before move'', ''/evidence-egress'', ''where are the duplicates''.' +canon_uri: chittycanon://core/services/chittymarket#skills/evidence-egress +--- + +# Evidence Egress — Audit Before You Move + +## Principle (BINDING) + +**Three-state rule.** Every evidence byte must exist in at least 2 of: + +1. **Canonical** — `chittyevidence-documents/sha256/` in R2 (source of truth) +2. **Mirror** — `sd_:` Google Drive (human-browsable, shareable) +3. **Working copy** — local case dir (or stick when chittymemory-00 exists) + +**No source file is ever deleted before its canonical (1) AND one of (2/3) are verified.** + +**Identity is content hash.** Never collapse documents by title, date, filename, or path — see [[feedback_version_authority]]. Two PDFs with the same name are not the same document; two PDFs with the same sha256 are. + +## What This Skill Does + +INDEX → CHECK → DRIVE → REPORT. Read-only. + +- **INDEX**: walks `/cases//`, sha256s every document-type file (configurable), excludes code subtrees (`node_modules/`, `bin/`, `.git/`, presence of `package.json` or `pyproject.toml` at subtree root). +- **CHECK**: batches hashes against Neon `storage.documents` (or `evidence_documents` — schema-discovered). Each file annotated `in_neon=yes|no`. +- **DRIVE**: resolves Drive remote per case using convention `sd_:`. If remote exists, walks it once, builds a name+size index, matches local files. Each file annotated `in_drive=yes|no|no_remote`. +- **REPORT**: emits `/tmp/egress--.csv` with columns: `path, sha256, size, mtime, in_neon, in_drive, action`. Plus a summary report. + +`action` values: +| Value | Meaning | +|---|---| +| `safe_to_delete` | in_neon=yes AND (in_drive=yes OR working_copy_planned) | +| `ingest_then_delete` | in_neon=no — must run pipeline-submit before delete | +| `verify_drive` | in_neon=yes but in_drive=no AND no working copy planned — push to Drive first | +| `no_remote_review` | drive remote missing for this case — manual decision | +| `skip_code` | file is in code subtree, not document | +| `skip_empty` | zero-byte file | +| `skip_dotfile` | hidden file (.DS_Store, .git/*, etc.) | + +INGEST, MOVE, DELETE are **separate explicit subcommands** — not run by the audit. + +## Triggers + +Use this skill BEFORE moving, deleting, or reorganizing any directory containing legal/evidence/case material — even if "just freeing up space." Specifically: +- "Move ~/Desktop/organized/Legal somewhere" +- "Clean up iCloud — evidence is everywhere" +- "Free up the Downloads folder" +- "Migrate cases to the stick / external drive" +- "Find dups across local + Drive + R2" + +## Usage + +```bash +# 1. Discover cases under a root +~/.claude/skills/evidence-egress/scripts/discover.sh ~/Desktop/organized/Legal + +# 2. Audit one case (produces /tmp/egress--.csv) +~/.claude/skills/evidence-egress/scripts/audit.sh \ + --root ~/Desktop/organized/Legal \ + --case arias_v_bianchi + +# 3. Audit all discovered cases under a root +~/.claude/skills/evidence-egress/scripts/audit.sh \ + --root ~/Desktop/organized/Legal --all + +# 4. Show summary of last run +~/.claude/skills/evidence-egress/scripts/report.sh --summary +``` + +## Dependencies + +Verified by `discover.sh --check`: +- `sha256sum` or `shasum` +- `rclone` with case-specific remotes (`sd_:`) +- `psql` + `NEON_DATABASE_URL` env (brokered via ChittyConnect / ChittySecrets, configured in `assets/neon-source.sh`) +- Optional: `chitty_evidence_search` MCP tool as fallback for Neon access + +## Configuration + +`assets/config.json`: +- `document_extensions` — list (default below) +- `code_marker_files` — files whose presence flags a subtree as code (`package.json`, `pyproject.toml`, `Cargo.toml`, `go.mod`) +- `code_marker_dirs` — `node_modules`, `.git`, `__pycache__`, `dist`, `build`, `.next` +- `drive_remote_pattern` — default `sd_` (template) +- `neon_table` — default tries `storage.documents` then `evidence_documents` +- `neon_hash_column` — default `content_hash` + +Default document extensions: `pdf eml docx doc txt csv zip jpg jpeg png heic tiff mp3 m4a caf wav xlsx xls pptx rtf html htm` + +## What This Skill Does NOT Do + +- Does NOT move files (use `scripts/move.sh` separately after review) +- Does NOT delete files (use `scripts/cleanup.sh` separately after review) +- Does NOT push to Drive (use `pipeline-submit` skill for ingestion) +- Does NOT classify documents (that's the pipeline worker's job) +- Does NOT touch code subtrees — they're skipped, you handle them separately + +## Anti-Patterns + +- **Never** combine audit + move + delete in one run. Audit is read-only by design. +- **Never** delete source based on filename/path match. Hash match only. +- **Never** assume a Drive mirror is complete. Verify with `rclone size` + sample reads. +- **Never** skip the in_neon check because "we ingested it last week." Hash is truth. + +## State + +Run state at `~/.claude/skills/evidence-egress/assets/state.json`. Reports at `/tmp/egress--.csv`. Old reports cleaned after 30 days. + +## Related + +- [[evidence-collect]] — canonical ingestion pipeline (the IN side of this skill's egress) +- [[pipeline-submit]] — actual ingestion command for `ingest_then_delete` action items +- [[fact-governance]] — fact lifecycle (versioning, locking) — egress preserves all versions, never collapses +- [[machine-management]] — the broader storage lifecycle this fits into diff --git a/plugins/chittyos-legal/gemini-skills/fact-governance/SKILL.md b/plugins/chittyos-legal/gemini-skills/fact-governance/SKILL.md new file mode 100644 index 0000000..8f82ae2 --- /dev/null +++ b/plugins/chittyos-legal/gemini-skills/fact-governance/SKILL.md @@ -0,0 +1,191 @@ +--- +name: fact-governance +description: Evidence fact governance for a specified case. Triggers on "fact", "evidence", "verify", "verification", case materials, dates/amounts/claims, or chittyevidence-db operations. REQUIRES an explicit `case` parameter — refuses to run without one. Manages fact lifecycle (draft→verified→locked), versioning, corrections, and Notion sync. +canon_uri: chittycanon://core/services/chittymarket#skills/fact-governance +--- + +# Fact Governance — Evidence Pipeline + +## Required: `case` parameter + +This skill **requires** an explicit case identifier on every invocation. It MUST NOT default to any particular case. + +Accept either: + +- **`case_id`** — the chittyevidence-db case identifier (e.g. `arias-v-bianchi-2024d007847`) +- **`case_slug`** — a registered case slug (resolve via `evidence_cases` or the chittyrouter case registry) + +If no `case` is specified, stop and ask the caller for one. Do not fall back to any previously-used case. + +Every SQL example below uses `` as a placeholder — substitute the resolved case at runtime. Do not paste literal case IDs. + +## Database Integration + +- **Database:** chittyevidence-db +- **ID:** f486fed7-cba9-47d2-93fb-ca11d90ca084 +- **Case ID:** provided per invocation (never hardcoded) +- **Table:** evidence_statement_of_facts + +### Schema + +```sql +evidence_statement_of_facts ( + id TEXT PRIMARY KEY, + case_id TEXT, + fact_number INTEGER NOT NULL, + fact_date TEXT, + fact_text TEXT NOT NULL, + exhibit_reference TEXT NOT NULL, -- REQUIRED + document_id TEXT, + source_quote TEXT, + has_conflict INTEGER DEFAULT 0, + conflict_with_fact_id TEXT, + created_at TEXT, + status TEXT DEFAULT 'draft', -- draft|verified|locked|disputed|archived|rejected + version INTEGER DEFAULT 1, + category TEXT, -- CORP|PROP|TIME|FIN|CONT|PROC|ADM|EVID + verified_by TEXT, + verified_at TEXT, + supersedes_id TEXT, + updated_at TEXT, + submitted_by TEXT +) +``` + +### Related Tables + +- `evidence_correction_queue` — Corrections workflow +- `evidence_correction_audit_log` — Audit trail +- `evidence_review_queue` — Review workflow +- `evidence_provenance_records` — State tracking +- `evidence_chain_of_custody` — Chain of custody + +## Status Lifecycle + +| Status | Can Edit | Transitions To | +|--------|----------|----------------| +| draft | Yes | verified, rejected, disputed | +| verified | Correction only | locked, disputed, archived | +| locked | Never | (immutable) | +| disputed | Notes only | draft, verified | +| archived | Never | (immutable) | +| rejected | Never | (immutable) | + +## Categories + +| Code | Name | +|------|------| +| CORP | Corporate (LLC, membership, governance) | +| PROP | Property (real estate, deeds) | +| TIME | Timeline (dated events) | +| FIN | Financial (amounts, transactions) | +| CONT | Contradiction (claim vs counter-evidence) | +| PROC | Procedural (docket, filings, orders) | +| ADM | Admission (party statements) | +| EVID | Evidence (document existence/location) | + +## Operations + +In every SQL below, `` means the resolved case identifier for THIS invocation. Never paste a literal case string. + +### Add Fact +```sql +INSERT INTO evidence_statement_of_facts ( + id, case_id, fact_number, fact_date, fact_text, + exhibit_reference, document_id, source_quote, + status, version, category, submitted_by, created_at, updated_at +) VALUES ( + 'FACT-' || hex(randomblob(8)), + ?, -- + (SELECT COALESCE(MAX(fact_number), 0) + 1 FROM evidence_statement_of_facts WHERE case_id = ?), + ?, ?, ?, ?, ?, 'draft', 1, ?, ?, datetime('now'), datetime('now') +); +``` + +### Verify Fact +```sql +UPDATE evidence_statement_of_facts +SET status = 'verified', verified_by = ?, verified_at = datetime('now'), updated_at = datetime('now') +WHERE id = ? AND case_id = ? AND status = 'draft'; +``` + +### Lock Fact +```sql +UPDATE evidence_statement_of_facts +SET status = 'locked', updated_at = datetime('now') +WHERE id = ? AND case_id = ? AND status = 'verified'; +``` + +### Correct Fact (creates new version) +1. Archive old: `UPDATE ... SET status = 'archived' WHERE id = ? AND case_id = ? AND status IN ('draft', 'verified')` +2. Insert new version with `supersedes_id` pointing to old, `version + 1`, status = 'draft', same `case_id` +3. Log to `evidence_correction_audit_log` + +### Flag Dispute +```sql +UPDATE evidence_statement_of_facts +SET status = 'disputed', has_conflict = 1, conflict_with_fact_id = ?, updated_at = datetime('now') +WHERE id = ? AND case_id = ?; +``` + +## Query Helpers + +Every query is case-scoped via `case_id = ?`. Never omit it. + +```sql +-- All active facts for the resolved case +SELECT * FROM evidence_statement_of_facts +WHERE case_id = ? + AND status NOT IN ('archived', 'rejected') +ORDER BY category, fact_number; + +-- Pending review within the resolved case +SELECT * FROM evidence_statement_of_facts +WHERE case_id = ? AND status = 'draft' +ORDER BY created_at; + +-- Fact history (within the resolved case) +WITH RECURSIVE fact_history AS ( + SELECT * FROM evidence_statement_of_facts WHERE id = ? AND case_id = ? + UNION ALL + SELECT f.* FROM evidence_statement_of_facts f + JOIN fact_history h ON f.id = h.supersedes_id AND f.case_id = h.case_id +) +SELECT * FROM fact_history ORDER BY version DESC; +``` + +## Validation Rules + +1. `exhibit_reference` is **REQUIRED** — every fact needs a source. +2. Check status before any UPDATE — locked facts are immutable. +3. Corrections create new versions — never UPDATE locked/verified fact_text. +4. Valid transitions only (see lifecycle table). +5. **Every write and read MUST include `case_id = ?` in its WHERE clause.** Cross-case leaks are the exact class of bug this skill must prevent. +6. On insert, verify `case_id` matches the resolved case from the invocation parameter — reject mismatches. + +## Notion Sync + +Notion Evidence Tracker lives under `ChittyLedger → → Evidence Tracker`. The target workspace is selected from the resolved case's Notion mapping (via case registry metadata or Notion Projects DB lookup by `case_slug`). Never write facts from case A into case B's Notion workspace. + +- New D1 facts → Create Notion entry in the case's workspace +- Status changes → Update corresponding Notion entry (same workspace) +- Weekly reconciliation for drift — case-scoped + +## Quick Reference + +**Can I edit?** +- draft → YES +- verified → Correction only (new version) +- locked/archived/rejected → NO +- disputed → Notes only + +**ID Formats:** +- Internal: `FACT-{hex}` (e.g., FACT-a1b2c3d4e5f6) +- Display: `{CAT}-{NUM}.{VER}` (e.g., CORP-001.1, TIME-042.2) — fact_number is scoped per-case + +## Invocation Rejection + +If invoked without a `case` parameter, the skill MUST: +1. Refuse to proceed. +2. Return: "fact-governance: no `case` specified — refusing to run. Provide `case_id=` or `case_slug=`." +3. List the caller's currently-active cases so they can pick one. diff --git a/plugins/chittyos-mcp/gemini-skills/cast/SKILL.md b/plugins/chittyos-mcp/gemini-skills/cast/SKILL.md new file mode 100644 index 0000000..7d71206 --- /dev/null +++ b/plugins/chittyos-mcp/gemini-skills/cast/SKILL.md @@ -0,0 +1,65 @@ +--- +name: cast +description: Route an intent through ch1tty/cast — the canonical orchestration entry point of the MCP hierarchy (ch1tty umbrella over ChittyMCP, Cloudflare MCP, GitHub MCP, Notion MCP, Neon MCP, etc.). Triggers on "/cast" or when the user wants to invoke ch1tty cast directly. Use ch1tty/cast for orchestration, intent-driven work, "I want to do X find the right tool", or cross-backend composition. Raw backend tools (mcp__claude_ai_ChittyMCP__*, raw Cloudflare/GitHub/Notion) bypass the hierarch — out of contract per ch1tty README. Cast loads the SessionCoordinator affinity + Alchemist pattern observation + focus-profile lens biasing. +canon_uri: chittycanon://core/services/chittymarket#skills/cast +--- + +# /cast — Route an intent through the ch1tty hierarch + +The user invoked `/cast` to send an intent through ch1tty's canonical cast entry. Treat the rest of the user's message as the natural-language intent. + +## What to do + +1. Read the user's arguments as the intent string. +2. Invoke `ch1tty/cast` via the available ch1tty MCP tool (`mcp__claude_ai_Ch1tty__cast` if connected; otherwise via `mcp__claude_ai_ChittyMCP__*` only as last-resort fallback with explicit caveat that this bypasses the hierarch). +3. If the cast result needs confirmation (`confirm: true` flow) or has multiple candidates, surface them to the user with the top match + alternates. +4. Execute the selected tool; return the result. + +## Why /cast, not raw tools + +The MCP hierarchy is: + +``` +ch1tty/cast ─────► routes to the right backend +ch1tty/search ───► discovers candidates +ch1tty/execute ──► invokes a known namespaced tool + │ + ├── ChittyMCP (mcp.chitty.cc, 167 tools) + ├── Cloudflare MCP + ├── GitHub MCP + ├── Notion MCP + ├── Neon MCP + └── future backends +``` + +Ch1tty's README contract: *"If the runtime exposes raw backend tools directly, the deployment is out of contract."* Reaching for `mcp__claude_ai_ChittyMCP__tasks_list` directly bypasses: +- **SessionCoordinator** affinity tracking (it observes which tools you compose) +- **Alchemist** cross-backend pattern recognition (it promotes recurring patterns into focused `apps/*-mcp` services) +- **Focus profiles** (finance / governance / design) which only bias cast/search ordering +- **Cross-backend composition** — only cast can chain GitHub + Notion + Neon in one intent + +## Constraints on cast usage + +- The intent should be specific enough for cast to resolve: "create a stripe invoice for X" is good; "do something with stripe" is too vague. +- For `confirm: true` casts, surface the plan to the user before executing if the operation is mutating or irreversible. +- If cast returns no match, fall back to `ch1tty/search` with the intent's keywords, then `ch1tty/execute` once a candidate is chosen — **not** to a raw backend tool. +- Only fall back to a raw backend tool (`mcp__claude_ai_ChittyMCP__*` etc.) if cast and search both genuinely fail to surface the right candidate. Note the fallback explicitly so the user knows the hierarch was bypassed. + +## Examples + +- `/cast pull the latest 5 closing-disclosure facts from evidence and write a Notion brief` — cross-backend, cast resolves the chain. +- `/cast show me all open chittyconnect issues` — cast routes to GitHub MCP via the github backend. +- `/cast triage today's incoming tasks from the durable board` — cast routes to chittyagent-tasks via ChittyMCP. +- `/cast what does the alchemist suggest for the governance focus this week?` — cast routes to the alchemist tools. + +## When NOT to use /cast + +- Single, known, well-defined raw tool call where you're absolutely certain of the tool name AND the work won't benefit from coordinator affinity / alchemist observation (e.g. a one-off `tasks_claim` with a known task_id). Even then, briefly note that you're bypassing the hierarch. +- Pure local file/git work — that's not an MCP-routable intent. + +## See also + +- Skill `chittyhelper` (`/helper`) — architectural navigator for "which service handles X?" +- Skill `chico` (`/chico`) — the ChittyConnect concierge for the credential lane. +- `nb-development-defaults` → "MCP Hierarchy — ch1tty is the umbrella" — the binding default rule. +- ch1tty repo: `docs/MCP_HOST_STANDARD.md`, `README.md` § Canonical Contract. diff --git a/plugins/chittyos-mcp/gemini-skills/chittygws/SKILL.md b/plugins/chittyos-mcp/gemini-skills/chittygws/SKILL.md new file mode 100644 index 0000000..5149802 --- /dev/null +++ b/plugins/chittyos-mcp/gemini-skills/chittygws/SKILL.md @@ -0,0 +1,59 @@ +--- +name: chittygws +description: Instructs agents on how to utilize the ChittyGWS surface (Google Workspace MCP). Covers connecting to ChittyGWS securely via Cloudflare Access JWT validation, dealing with MCP portal errors, and handling OAuth for external testing apps. Use when agents need to interact with Google Workspace APIs via the MCP server or troubleshoot 404/421/503 errors on the MCP portal. +canon_uri: chittycanon://core/services/chittymarket#skills/chittygws +--- + +# ChittyGWS (Google Workspace MCP) + +This skill provides instructions for interacting with the ChittyGWS (Google Workspace) MCP surface, particularly regarding authentication, Cloudflare Access, and troubleshooting connection issues from ChatGPT or Claude via the MCP Portal. + +## Architecture & Authentication + +ChittyGWS is protected by Cloudflare Access. External clients (like ChatGPT or Claude) connecting through the MCP Portal (`https://chatgpt.com/connector/oauth/...`) do not bypass this protection. + +### Cloudflare Access JWT Validation + +When the MCP Portal makes a request to the ChittyGWS MCP endpoints (e.g., `/mcp`), it MUST include a valid Cloudflare Access JWT in the `Cf-Access-Jwt-Assertion` header. + +1. **Middleware (`verifyAccessJwt`)**: The ChittyGWS worker checks for the `Cf-Access-Jwt-Assertion` header. +2. **Validation**: It validates the token using the JWKS endpoint associated with your Cloudflare Zero Trust `TEAM_DOMAIN`. +3. **Audience Check**: The token's audience (`aud`) MUST match the `POLICY_AUD` configured in the worker's environment. + +**Reference**: [Validating JSON Web Tokens](https://developers.cloudflare.com/cloudflare-one/access-controls/applications/http-apps/authorization-cookie/validating-json/index.md) + +### Required Environment Variables + +For the ChittyGWS worker to successfully authenticate requests, the following environment variables MUST be correctly configured in `wrangler.jsonc` (or via Cloudflare Secrets): + +- `TEAM_DOMAIN`: The Cloudflare Zero Trust team domain (e.g., `https://your-team.cloudflareaccess.com`). +- `POLICY_AUD`: The Audience tag of the Cloudflare Access application protecting the MCP endpoint. + +*If either of these are empty or incorrect, the worker will fail to validate the JWT, resulting in `503 Service Unavailable` or `401 Unauthorized` errors.* + +## Troubleshooting MCP Portal Errors + +When users report errors like `HTTP 404`, `HTTP 421`, or `HTTP 503` in the MCP Portal: + +1. **HTTP 503 (Service Unavailable)**: + - **Cause**: Often caused by missing or misconfigured `TEAM_DOMAIN` or `POLICY_AUD` environment variables in the worker, causing the `verifyAccessJwt` middleware to fail. + - **Action**: Check `wrangler.jsonc` and ensure these variables are populated with the correct values from the Cloudflare Zero Trust dashboard. + +2. **HTTP 401 (Unauthorized)**: + - **Cause**: The `Cf-Access-Jwt-Assertion` header is missing, expired, or invalid. The MCP Portal (or proxy, like `chittyconnect`) might not be passing the header correctly. + - **Action**: Verify that the MCP Portal is correctly linked as an application in Cloudflare Access and that the service token or user session is valid. + +3. **HTTP 404 / 421**: + - **Cause**: Incorrect routing, the MCP server is down, or the endpoint URL is misconfigured in the MCP Portal. + - **Action**: Verify the MCP Server URL configured in the ChatGPT/Claude connector settings. + +## Google OAuth & Allow Lists + +ChittyGWS integrates with Google Workspace APIs via OAuth 2.0. + +- **External Testing Apps**: When the Google Cloud Project's OAuth consent screen is set to "External" and "Testing", ONLY users explicitly added to the "Test users" list in the GCP Console can authorize the app. +- **No Additional Allow Lists Needed**: Because Google enforces the "Test users" list at the OAuth consent screen level, building an *additional* allow list within ChittyGWS is redundant and unnecessary. If a user can successfully complete the Google OAuth flow (e.g., receiving `{"success":true,"message":"Google OAuth completed"}`), they are already authorized. + +## Sensitive Information Guardrails + +**CRITICAL**: NEVER reveal API keys, Client IDs, Client Secrets, or other sensitive tokens in conversation history. Treat all values in `wrangler.jsonc`, `.dev.vars`, and Cloudflare Secrets as highly sensitive. Do not echo them back in plain text during debugging. diff --git a/plugins/chittyos-security/.claude-plugin/plugin.json b/plugins/chittyos-security/.claude-plugin/plugin.json new file mode 100644 index 0000000..5051722 --- /dev/null +++ b/plugins/chittyos-security/.claude-plugin/plugin.json @@ -0,0 +1,19 @@ +{ + "name": "chittyos-security", + "version": "0.1.0", + "description": "ChittyOS security review and threat modeling for Cloudflare Workers, MCP boundaries, secrets, data stores, and Workers Builds", + "author": { + "name": "ChittyOS", + "email": "dev@chitty.cc" + }, + "requires": ["chittyos-core"], + "keywords": [ + "security", + "threat-model", + "cloudflare", + "workers", + "mcp", + "secrets", + "compliance" + ] +} diff --git a/plugins/chittyos-security/README.md b/plugins/chittyos-security/README.md new file mode 100644 index 0000000..13240c8 --- /dev/null +++ b/plugins/chittyos-security/README.md @@ -0,0 +1,26 @@ +# chittyos-security + +ChittyOS security review and threat modeling for Cloudflare Workers, MCP boundaries, secrets, data stores, and Workers Builds. + +## Installation + +```bash +/plugin marketplace add +/plugin install chittyos-security@ +``` + +## Features + +- `chittyos-security-review` — read-only evidence-based security review. +- `chittyos-threat-model` — trust boundaries, abuse cases, ownership, and remediation planning. +- Cloudflare-native guidance for Workers, Workers AI, D1, Neon, R2, Ch1tty, and Workers Builds. +- Free-GitHub-compatible validation guidance with no duplicate deployment workflows. + +## Usage + +Use `chittyos-security-review` for a repository or change review. Use `chittyos-threat-model` when +the request involves system boundaries, abuse cases, ownership, or security architecture. + +## Development + +See [workflows.md](../../CLAUDE.md) for development guidelines. diff --git a/plugins/chittyos-security/codex-skills/chittyos-security-review/SKILL.md b/plugins/chittyos-security/codex-skills/chittyos-security-review/SKILL.md new file mode 100644 index 0000000..bd4a928 --- /dev/null +++ b/plugins/chittyos-security/codex-skills/chittyos-security-review/SKILL.md @@ -0,0 +1,53 @@ +--- +name: chittyos-security-review +description: | + Review ChittyOS code and configuration for security weaknesses across Cloudflare Workers, + Workers AI, MCP/Ch1tty boundaries, ChittyConnect and ChittySecrets, D1/Neon/R2, webhooks, + and Workers Builds. Triggers on security review, hardening, secret handling, auth boundary, + Worker security, MCP security, or threat-preflight requests. +canon_uri: chittycanon://core/services/chittymarket#skills/chittyos-security-review +--- + +# ChittyOS Security Review + +Perform a read-only, evidence-based review before proposing changes. Inspect the real repository, +its `CHARTER.md`, `CHITTY.md`, `CLAUDE.md`, `AGENTS.md`, Worker configuration, routes, bindings, +workflows, and tests. Do not request or expose credentials. + +## Review order + +1. Establish scope: repository, Worker/service, changed files, data handled, and deployment path. +2. Discover existing owners and canonical services before suggesting a new control. Reuse ChittyConnect, + ChittyAuth, ChittyID, ChittySecrets, ChittyCanon, ChittyTrack, and Ch1tty where applicable. +3. Trace trust boundaries: browser/client → Worker → MCP/Ch1tty → upstream service → D1/Neon/R2/KV. +4. Inspect authentication, authorization, tenant isolation, input validation, output handling, CORS, + webhook verification, replay protection, rate limits, and failure behavior. +5. Inspect `wrangler.toml`/`wrangler.jsonc`, bindings, routes, compatibility date, observability, + Workers Builds triggers, and GitHub workflows for secret leakage or fail-open deployment gates. +6. Check AI-specific risks: prompt injection, untrusted tool arguments, model-output trust, data leakage, + unbounded prompts/completions, provider fallback, usage limits, and generation persistence. +7. Classify each finding as critical, high, medium, low, or informational, with file/line evidence. + +## ChittyOS rules + +- Secrets and tokens are broker-managed. Never grep, print, paste, rotate, or invent secret values. +- Route credential and deployment intent through ChittyConnect/Chico; fail closed when the broker is unavailable. +- Treat Ch1tty as the MCP umbrella and do not bypass it for orchestration or intent-driven calls. +- Never treat KV as the authoritative store for security state, idempotency, audit, or custody records. +- Prefer Workers Builds for deployment. GitHub Actions may validate but must not become a deployment queue. +- Do not add paid-GitHub assumptions, broad workflow fan-out, or duplicate deploy workflows. +- Do not weaken auth, CORS, tenant boundaries, logging redaction, or deploy gates to make a test pass. +- Findings must distinguish a confirmed vulnerability from a missing control or an unverified assumption. + +## Output + +Return: + +1. Scope and evidence inspected. +2. Findings table: severity, evidence, impact, exploit/precondition, and recommended remediation. +3. Positive controls already present. +4. Prioritized remediation backlog with smallest safe next steps. +5. Tests or probes that would prove each fix. +6. Explicit caveats where runtime, registry, binding, or provider state was unavailable. + +Do not implement fixes, mutate infrastructure, or change credentials unless separately requested and approved. diff --git a/plugins/chittyos-security/codex-skills/chittyos-threat-model/SKILL.md b/plugins/chittyos-security/codex-skills/chittyos-threat-model/SKILL.md new file mode 100644 index 0000000..0f98cef --- /dev/null +++ b/plugins/chittyos-security/codex-skills/chittyos-threat-model/SKILL.md @@ -0,0 +1,53 @@ +--- +name: chittyos-threat-model +description: | + Build a practical threat model for ChittyOS services and workflows, including Cloudflare Workers, + AI inference, MCP tools, webhooks, D1/Neon/R2 data flows, service ownership, and Workers Builds. + Triggers on threat model, abuse cases, attack surface, security architecture, or ownership map requests. +canon_uri: chittycanon://core/services/chittymarket#skills/chittyos-threat-model +--- + +# ChittyOS Threat Model + +Create a bounded threat model from repository evidence. This is a design and review artifact, not an +authorization to deploy, change permissions, or modify production data. + +## Method + +1. Define the system, intended users, protected assets, security objectives, and explicit out-of-scope areas. +2. Map components and trust boundaries using actual routes, bindings, MCP tools, queues, databases, buckets, + AI providers, and build/deploy triggers. +3. Build an ownership map: service/repository, canonical owner, data owner, deploy authority, secret broker, + downstream consumers, and evidence source. Mark unknown ownership as a finding. +4. Enumerate abuse cases for spoofing, tampering, repudiation, information disclosure, denial of service, + and privilege escalation. Include AI prompt/tool abuse and webhook replay where relevant. +5. Rank risks by likelihood, impact, exploitability, and blast radius. Separate design risk from confirmed exposure. +6. Identify preventive, detective, and recovery controls. Prefer existing ChittyOS primitives over new infrastructure. +7. Produce a minimal remediation sequence and verification plan. + +## Required checks + +- Authn and authz are enforced at every externally reachable route and tool boundary. +- Tenant/user scope is carried through reads, writes, background jobs, and result retrieval. +- Webhooks authenticate payloads, reject stale/replayed events, and handle duplicate delivery safely. +- AI tools constrain arguments, validate model output before side effects, and cap input/output/resource usage. +- Prompts, outputs, tokens, headers, and secret material are not written to logs or public storage. +- D1/Neon/R2 permissions follow least privilege and large/sensitive objects have retention controls. +- Worker restarts, client disconnects, retries, and provider failures do not create fail-open state. +- Workers Builds and GitHub checks cannot silently bypass required validation or deploy authorization. +- Ownership, escalation path, and evidence links are recorded for every high-risk asset. + +## Output + +Return: + +- system and trust-boundary summary; +- asset/owner/data-flow table; +- prioritized STRIDE-style abuse-case table; +- existing controls and control gaps; +- remediation backlog with owner, dependency, and verification test; +- residual risk and assumptions; +- explicit human-review items for deploy, credential custody, destructive actions, or external communication. + +Never claim a service is secure merely because tests pass. A threat model is complete only when unknown +boundaries and ownership are called out, not silently assumed away. diff --git a/plugins/chittyos-security/gemini-skills/chittyos-security-review/SKILL.md b/plugins/chittyos-security/gemini-skills/chittyos-security-review/SKILL.md new file mode 100644 index 0000000..bd4a928 --- /dev/null +++ b/plugins/chittyos-security/gemini-skills/chittyos-security-review/SKILL.md @@ -0,0 +1,53 @@ +--- +name: chittyos-security-review +description: | + Review ChittyOS code and configuration for security weaknesses across Cloudflare Workers, + Workers AI, MCP/Ch1tty boundaries, ChittyConnect and ChittySecrets, D1/Neon/R2, webhooks, + and Workers Builds. Triggers on security review, hardening, secret handling, auth boundary, + Worker security, MCP security, or threat-preflight requests. +canon_uri: chittycanon://core/services/chittymarket#skills/chittyos-security-review +--- + +# ChittyOS Security Review + +Perform a read-only, evidence-based review before proposing changes. Inspect the real repository, +its `CHARTER.md`, `CHITTY.md`, `CLAUDE.md`, `AGENTS.md`, Worker configuration, routes, bindings, +workflows, and tests. Do not request or expose credentials. + +## Review order + +1. Establish scope: repository, Worker/service, changed files, data handled, and deployment path. +2. Discover existing owners and canonical services before suggesting a new control. Reuse ChittyConnect, + ChittyAuth, ChittyID, ChittySecrets, ChittyCanon, ChittyTrack, and Ch1tty where applicable. +3. Trace trust boundaries: browser/client → Worker → MCP/Ch1tty → upstream service → D1/Neon/R2/KV. +4. Inspect authentication, authorization, tenant isolation, input validation, output handling, CORS, + webhook verification, replay protection, rate limits, and failure behavior. +5. Inspect `wrangler.toml`/`wrangler.jsonc`, bindings, routes, compatibility date, observability, + Workers Builds triggers, and GitHub workflows for secret leakage or fail-open deployment gates. +6. Check AI-specific risks: prompt injection, untrusted tool arguments, model-output trust, data leakage, + unbounded prompts/completions, provider fallback, usage limits, and generation persistence. +7. Classify each finding as critical, high, medium, low, or informational, with file/line evidence. + +## ChittyOS rules + +- Secrets and tokens are broker-managed. Never grep, print, paste, rotate, or invent secret values. +- Route credential and deployment intent through ChittyConnect/Chico; fail closed when the broker is unavailable. +- Treat Ch1tty as the MCP umbrella and do not bypass it for orchestration or intent-driven calls. +- Never treat KV as the authoritative store for security state, idempotency, audit, or custody records. +- Prefer Workers Builds for deployment. GitHub Actions may validate but must not become a deployment queue. +- Do not add paid-GitHub assumptions, broad workflow fan-out, or duplicate deploy workflows. +- Do not weaken auth, CORS, tenant boundaries, logging redaction, or deploy gates to make a test pass. +- Findings must distinguish a confirmed vulnerability from a missing control or an unverified assumption. + +## Output + +Return: + +1. Scope and evidence inspected. +2. Findings table: severity, evidence, impact, exploit/precondition, and recommended remediation. +3. Positive controls already present. +4. Prioritized remediation backlog with smallest safe next steps. +5. Tests or probes that would prove each fix. +6. Explicit caveats where runtime, registry, binding, or provider state was unavailable. + +Do not implement fixes, mutate infrastructure, or change credentials unless separately requested and approved. diff --git a/plugins/chittyos-security/gemini-skills/chittyos-threat-model/SKILL.md b/plugins/chittyos-security/gemini-skills/chittyos-threat-model/SKILL.md new file mode 100644 index 0000000..0f98cef --- /dev/null +++ b/plugins/chittyos-security/gemini-skills/chittyos-threat-model/SKILL.md @@ -0,0 +1,53 @@ +--- +name: chittyos-threat-model +description: | + Build a practical threat model for ChittyOS services and workflows, including Cloudflare Workers, + AI inference, MCP tools, webhooks, D1/Neon/R2 data flows, service ownership, and Workers Builds. + Triggers on threat model, abuse cases, attack surface, security architecture, or ownership map requests. +canon_uri: chittycanon://core/services/chittymarket#skills/chittyos-threat-model +--- + +# ChittyOS Threat Model + +Create a bounded threat model from repository evidence. This is a design and review artifact, not an +authorization to deploy, change permissions, or modify production data. + +## Method + +1. Define the system, intended users, protected assets, security objectives, and explicit out-of-scope areas. +2. Map components and trust boundaries using actual routes, bindings, MCP tools, queues, databases, buckets, + AI providers, and build/deploy triggers. +3. Build an ownership map: service/repository, canonical owner, data owner, deploy authority, secret broker, + downstream consumers, and evidence source. Mark unknown ownership as a finding. +4. Enumerate abuse cases for spoofing, tampering, repudiation, information disclosure, denial of service, + and privilege escalation. Include AI prompt/tool abuse and webhook replay where relevant. +5. Rank risks by likelihood, impact, exploitability, and blast radius. Separate design risk from confirmed exposure. +6. Identify preventive, detective, and recovery controls. Prefer existing ChittyOS primitives over new infrastructure. +7. Produce a minimal remediation sequence and verification plan. + +## Required checks + +- Authn and authz are enforced at every externally reachable route and tool boundary. +- Tenant/user scope is carried through reads, writes, background jobs, and result retrieval. +- Webhooks authenticate payloads, reject stale/replayed events, and handle duplicate delivery safely. +- AI tools constrain arguments, validate model output before side effects, and cap input/output/resource usage. +- Prompts, outputs, tokens, headers, and secret material are not written to logs or public storage. +- D1/Neon/R2 permissions follow least privilege and large/sensitive objects have retention controls. +- Worker restarts, client disconnects, retries, and provider failures do not create fail-open state. +- Workers Builds and GitHub checks cannot silently bypass required validation or deploy authorization. +- Ownership, escalation path, and evidence links are recorded for every high-risk asset. + +## Output + +Return: + +- system and trust-boundary summary; +- asset/owner/data-flow table; +- prioritized STRIDE-style abuse-case table; +- existing controls and control gaps; +- remediation backlog with owner, dependency, and verification test; +- residual risk and assumptions; +- explicit human-review items for deploy, credential custody, destructive actions, or external communication. + +Never claim a service is secure merely because tests pass. A threat model is complete only when unknown +boundaries and ownership are called out, not silently assumed away. diff --git a/plugins/chittyos-security/skills/chittyos-security-review/SKILL.md b/plugins/chittyos-security/skills/chittyos-security-review/SKILL.md new file mode 100644 index 0000000..bd4a928 --- /dev/null +++ b/plugins/chittyos-security/skills/chittyos-security-review/SKILL.md @@ -0,0 +1,53 @@ +--- +name: chittyos-security-review +description: | + Review ChittyOS code and configuration for security weaknesses across Cloudflare Workers, + Workers AI, MCP/Ch1tty boundaries, ChittyConnect and ChittySecrets, D1/Neon/R2, webhooks, + and Workers Builds. Triggers on security review, hardening, secret handling, auth boundary, + Worker security, MCP security, or threat-preflight requests. +canon_uri: chittycanon://core/services/chittymarket#skills/chittyos-security-review +--- + +# ChittyOS Security Review + +Perform a read-only, evidence-based review before proposing changes. Inspect the real repository, +its `CHARTER.md`, `CHITTY.md`, `CLAUDE.md`, `AGENTS.md`, Worker configuration, routes, bindings, +workflows, and tests. Do not request or expose credentials. + +## Review order + +1. Establish scope: repository, Worker/service, changed files, data handled, and deployment path. +2. Discover existing owners and canonical services before suggesting a new control. Reuse ChittyConnect, + ChittyAuth, ChittyID, ChittySecrets, ChittyCanon, ChittyTrack, and Ch1tty where applicable. +3. Trace trust boundaries: browser/client → Worker → MCP/Ch1tty → upstream service → D1/Neon/R2/KV. +4. Inspect authentication, authorization, tenant isolation, input validation, output handling, CORS, + webhook verification, replay protection, rate limits, and failure behavior. +5. Inspect `wrangler.toml`/`wrangler.jsonc`, bindings, routes, compatibility date, observability, + Workers Builds triggers, and GitHub workflows for secret leakage or fail-open deployment gates. +6. Check AI-specific risks: prompt injection, untrusted tool arguments, model-output trust, data leakage, + unbounded prompts/completions, provider fallback, usage limits, and generation persistence. +7. Classify each finding as critical, high, medium, low, or informational, with file/line evidence. + +## ChittyOS rules + +- Secrets and tokens are broker-managed. Never grep, print, paste, rotate, or invent secret values. +- Route credential and deployment intent through ChittyConnect/Chico; fail closed when the broker is unavailable. +- Treat Ch1tty as the MCP umbrella and do not bypass it for orchestration or intent-driven calls. +- Never treat KV as the authoritative store for security state, idempotency, audit, or custody records. +- Prefer Workers Builds for deployment. GitHub Actions may validate but must not become a deployment queue. +- Do not add paid-GitHub assumptions, broad workflow fan-out, or duplicate deploy workflows. +- Do not weaken auth, CORS, tenant boundaries, logging redaction, or deploy gates to make a test pass. +- Findings must distinguish a confirmed vulnerability from a missing control or an unverified assumption. + +## Output + +Return: + +1. Scope and evidence inspected. +2. Findings table: severity, evidence, impact, exploit/precondition, and recommended remediation. +3. Positive controls already present. +4. Prioritized remediation backlog with smallest safe next steps. +5. Tests or probes that would prove each fix. +6. Explicit caveats where runtime, registry, binding, or provider state was unavailable. + +Do not implement fixes, mutate infrastructure, or change credentials unless separately requested and approved. diff --git a/plugins/chittyos-security/skills/chittyos-threat-model/SKILL.md b/plugins/chittyos-security/skills/chittyos-threat-model/SKILL.md new file mode 100644 index 0000000..0f98cef --- /dev/null +++ b/plugins/chittyos-security/skills/chittyos-threat-model/SKILL.md @@ -0,0 +1,53 @@ +--- +name: chittyos-threat-model +description: | + Build a practical threat model for ChittyOS services and workflows, including Cloudflare Workers, + AI inference, MCP tools, webhooks, D1/Neon/R2 data flows, service ownership, and Workers Builds. + Triggers on threat model, abuse cases, attack surface, security architecture, or ownership map requests. +canon_uri: chittycanon://core/services/chittymarket#skills/chittyos-threat-model +--- + +# ChittyOS Threat Model + +Create a bounded threat model from repository evidence. This is a design and review artifact, not an +authorization to deploy, change permissions, or modify production data. + +## Method + +1. Define the system, intended users, protected assets, security objectives, and explicit out-of-scope areas. +2. Map components and trust boundaries using actual routes, bindings, MCP tools, queues, databases, buckets, + AI providers, and build/deploy triggers. +3. Build an ownership map: service/repository, canonical owner, data owner, deploy authority, secret broker, + downstream consumers, and evidence source. Mark unknown ownership as a finding. +4. Enumerate abuse cases for spoofing, tampering, repudiation, information disclosure, denial of service, + and privilege escalation. Include AI prompt/tool abuse and webhook replay where relevant. +5. Rank risks by likelihood, impact, exploitability, and blast radius. Separate design risk from confirmed exposure. +6. Identify preventive, detective, and recovery controls. Prefer existing ChittyOS primitives over new infrastructure. +7. Produce a minimal remediation sequence and verification plan. + +## Required checks + +- Authn and authz are enforced at every externally reachable route and tool boundary. +- Tenant/user scope is carried through reads, writes, background jobs, and result retrieval. +- Webhooks authenticate payloads, reject stale/replayed events, and handle duplicate delivery safely. +- AI tools constrain arguments, validate model output before side effects, and cap input/output/resource usage. +- Prompts, outputs, tokens, headers, and secret material are not written to logs or public storage. +- D1/Neon/R2 permissions follow least privilege and large/sensitive objects have retention controls. +- Worker restarts, client disconnects, retries, and provider failures do not create fail-open state. +- Workers Builds and GitHub checks cannot silently bypass required validation or deploy authorization. +- Ownership, escalation path, and evidence links are recorded for every high-risk asset. + +## Output + +Return: + +- system and trust-boundary summary; +- asset/owner/data-flow table; +- prioritized STRIDE-style abuse-case table; +- existing controls and control gaps; +- remediation backlog with owner, dependency, and verification test; +- residual risk and assumptions; +- explicit human-review items for deploy, credential custody, destructive actions, or external communication. + +Never claim a service is secure merely because tests pass. A threat model is complete only when unknown +boundaries and ownership are called out, not silently assumed away. diff --git a/plugins/neon-mcp/.mcp.json b/plugins/neon-mcp/.mcp.json index c1b853a..974b076 100644 --- a/plugins/neon-mcp/.mcp.json +++ b/plugins/neon-mcp/.mcp.json @@ -4,7 +4,9 @@ "command": "/bin/sh", "args": [ "-lc", - "exec npx -y @neondatabase/mcp-server-neon start \"$NEON_API_KEY\"" + { + "case \"$NEON_API_KEY\" in \"\"|*://*) echo \"POLICY_BLOCKED_CREDENTIAL_UNRESOLVED": "neon-mcp NEON_API_KEY is an unresolved broker reference, not a token. Route through ChittyConnect (/chico). Refusing to start.\" >&2; exit 78;; esac; exec npx -y @neondatabase/mcp-server-neon start \"$NEON_API_KEY\"" + } ], "env": { "NEON_API_KEY": "chittysecrets://NEON_API_KEY" diff --git a/plugins/nowebmaster/gemini-skills/cli-surface-projection/SKILL.md b/plugins/nowebmaster/gemini-skills/cli-surface-projection/SKILL.md new file mode 100644 index 0000000..c2e82cf --- /dev/null +++ b/plugins/nowebmaster/gemini-skills/cli-surface-projection/SKILL.md @@ -0,0 +1,42 @@ +--- +name: cli-surface-projection +description: | + Runbook and CLI command projection for managing nowebmaster capabilities via chittycan (can wm & can surface). +canon_uri: chittycanon://core/services/chittymarket#skills/cli-surface-projection +--- + +# CLI Surface Projection — `chittycan` (`can`) + +## 1. CLI Projection Overview + +The **CLI Surface Projection** projects `nowebmaster` canonical atoms and lifecycle operations directly into terminal interfaces via **`chittycan`** (`can`). + +--- + +## 2. Command Reference + +### A. `can wm` Subcommands + +```bash +# Harvest & atomize any URL +can wm harvest [--content=""] + +# Cross-reference claim against canonical store +can wm check "" + +# Submit user flag & issue reward points +can wm flag "" --by= + +# Generate B2G / Enterprise contradiction priority report +can wm report [--format=markdown|json] [--out=] +``` + +### B. `can surface` Subcommands + +```bash +# Compile canonical atoms to provider surface molds +can surface compile --target=openai-mcp|openapi-3.1|claude-skill|cf-portal + +# Hot-load assembled bundle into live gateway +can surface hotload --portal=mcp-portal.chitty.cc +``` diff --git a/plugins/nowebmaster/gemini-skills/cross-surface-hotloading/SKILL.md b/plugins/nowebmaster/gemini-skills/cross-surface-hotloading/SKILL.md new file mode 100644 index 0000000..5bfefe0 --- /dev/null +++ b/plugins/nowebmaster/gemini-skills/cross-surface-hotloading/SKILL.md @@ -0,0 +1,58 @@ +--- +name: cross-surface-hotloading +description: | + Rules and runbook for projecting canonical atoms across OpenAI, Claude, Gemini, and Cloudflare surfaces. +canon_uri: chittycanon://core/services/chittymarket#skills/cross-surface-hotloading +--- + +# Cross-Surface Hot-Loading Runbook + +## 1. Provider Molds & Reassembly Specs + +| Target Surface | Reassembly Mold | Transport / Auth | Deployment API | +| :--- | :--- | :--- | :--- | +| **OpenAI Responses API** | `{ type: "mcp", server_url, allowed_tools }` | Streamable HTTP + Bearer Token | `POST /v1/responses` | +| **Custom GPTs** | OpenAPI 3.1 Schema + GPT Actions | REST + OAuth / API Key | ChatGPT GPT Builder API | +| **Claude Skills** | `.well-known/skills/index.json` + MCP refs | Streamable HTTP MCP | Claude MCP Settings Sync | +| **Gemini Gems / Extensions** | Vertex Extension Manifest + Function Declarations | Function Calling REST | Vertex AI Agent Builder API | +| **Cloudflare MCP Portal** | Server Registration + ZT Access Policy | Streamable HTTP + ZT OAuth | `POST /accounts/{id}/mcp/servers` | +| **ChittyOS Skins** | Skill Bundle (Tools + Prompts + Auth Keys) | Internal McpAgent Router | `registry.chitty.cc/api/v1/tools` | + +--- + +## 2. Compiler Pipeline Sequence + +``` +Canonical Atom Store (D1 wm_* tables + TypeBox/Zod schemas) + │ + ▼ + OpenAPI 3.1 Spec Generator (Source of truth contract) + │ + ┌────────┼───────────────────────┬───────────────────────┐ + ▼ ▼ ▼ ▼ +OpenAI Custom GPT Claude Skill CF MCP Portal +Plugin Actions Spec Manifest Index Server Reg +``` + +--- + +## 3. Surface-Specific Rules + +### Rule A: OpenAI Responses API (`type: "mcp"`) +- Tool definitions are lazy-loaded via `defer_loading: true`. +- Authentication passes via `authorization: "Bearer "`. +- Server must expose `GET/POST /mcp` implementing Streamable HTTP transport and JSON-RPC 2.0. + +### Rule B: Custom GPT Actions +- Requires OpenAPI 3.0/3.1 JSON/YAML spec. +- Operates over standard REST endpoints (not raw MCP). +- Naming convention: operation IDs must be `snake_case` (e.g., `webmaster_harvest`). + +### Rule C: Claude Skills +- Registered via `.well-known/skills/index.json`. +- Integrates multiple MCP server refs into a unified portable skill package. +- Respects open Agent Skills standard (Dec 2025). + +### Rule D: Cloudflare Zero Trust MCP Portal +- Serves as the authentication middleware between LLM clients and worker isolates. +- Registration payload posts to `https://mcp-portal.chitty.cc/mcp`. diff --git a/plugins/nowebmaster/gemini-skills/mcp-tool-calling-rules/SKILL.md b/plugins/nowebmaster/gemini-skills/mcp-tool-calling-rules/SKILL.md new file mode 100644 index 0000000..efc7f43 --- /dev/null +++ b/plugins/nowebmaster/gemini-skills/mcp-tool-calling-rules/SKILL.md @@ -0,0 +1,73 @@ +--- +name: mcp-tool-calling-rules +description: | + Invocation runbook and rules for calling webmaster_harvest, webmaster_check, and webmaster_flag. +canon_uri: chittycanon://core/services/chittymarket#skills/mcp-tool-calling-rules +--- + +# MCP Tool Invocation Rules for nowebmaster + +## 0. Implementation Drift (read first) + +This skill documents the **intended** contract. Two rules below are NOT yet implemented in `chittyagent-webmaster`: + +- **`batch()` atomicity in `webmaster_flag` is REQUIRED but ABSENT.** `webmaster-service.ts:156-186` issues two independent `.prepare().bind().run()` calls; there is no `.batch(` in `src/`. Treat the rule as binding-and-violated, not as a description of current behavior. +- **The `wm_*` tables have no DDL** anywhere in the monorepo. The tool handlers INSERT against unprovisioned tables. + +## 1. Tool Index & Signatures + +``` +CHITTYAGENT-WEBMASTER (chittycanon://core/services/chittyagent-webmaster) + ├── webmaster_harvest(url, content?) + ├── webmaster_check(source_url, claim_text) + └── webmaster_flag(url, description, flagged_by) +``` + +--- + +## 2. Invocation Protocols & Rules + +### Tool 1: `webmaster_harvest` +* **`tool_id`:** `webmaster_t_harvest` — `ontology_type: 'T'` (Thing) per `manifest.ts` +* **Input Schema:** + - `url` (string, required): Must be a valid `http://` or `https://` URL. + - `content` (string, optional): Raw markdown text if page is pre-harvested. +* **Database Behavior:** + - Inserts/updates `wm_pages` in `chittyevidence-db`. + - Uses `RETURNING id` on UPSERT (`ON CONFLICT(url)`) to prevent page ID desynchronization. +* **Return Shape:** + ```json + { + "status": "success", + "page_id": "page_12345678", + "url": "https://example.gov/docs", + "content_hash": "a1b2c3d4...", + "scraped_at": "2026-07-29T21:40:00.000Z" + } + ``` + +--- + +### Tool 2: `webmaster_check` +* **`tool_id`:** `webmaster_t_check` — `ontology_type: 'T'` (Thing) per `manifest.ts` +* **Input Schema:** + - `source_url` (string, required): Must be `http://` or `https://`. + - `claim_text` (string, required, min length 5): The factual claim to check. +* **Contradiction Evaluation Rules:** + - Stores claim in `wm_claims`. + - Performs cross-reference evaluation against claims from different URLs. + - Word boundary regexes (`\b... \b`) are enforced to prevent false-positive substring matches (e.g. `"must"` vs `"must not"`). + - Matches write to `wm_contradictions` with confidence `0.85` — a hardcoded SQL literal (`webmaster-service.ts:116`), not a computed default. + +--- + +### Tool 3: `webmaster_flag` +* **`tool_id`:** `webmaster_t_flag` — `ontology_type: 'T'` (Thing) per `manifest.ts` +* **Input Schema:** + - `url` (string, required): Target URL being reported. + - `description` (string, required, min length 5): Details of contradiction or decay. + - `flagged_by` (string, required, min length 1): Reporting user ID or handle. +* **Transaction Integrity Rules:** + - D1 `batch()` transaction is strictly required for atomic writes (**NOT YET IMPLEMENTED — see §0**): + - Insert into `wm_flags` (`reward_status = 'awarded'`, `points_awarded = 100`) + - Insert into `wm_rewards` (`source = 'wm_flag'`, `points = 100`) diff --git a/plugins/nowebmaster/gemini-skills/nowebmaster-architecture/SKILL.md b/plugins/nowebmaster/gemini-skills/nowebmaster-architecture/SKILL.md new file mode 100644 index 0000000..1771e96 --- /dev/null +++ b/plugins/nowebmaster/gemini-skills/nowebmaster-architecture/SKILL.md @@ -0,0 +1,62 @@ +--- +name: nowebmaster-architecture +description: | + Full architecture specification and 6-stage dynamic capability lifecycle pipeline for nowebmaster / webmastrai / GORE. +canon_uri: chittycanon://core/services/chittymarket#skills/nowebmaster-architecture +--- + +# nowebmaster Architecture & Substrate Specification + +## 1. Executive Summary & Vision + +**nowebmaster** (working names: *webmastrai*, *GORE — Global Omni Repository Endpoint*) is a universal capability lifecycle engine and automated webmaster. + +It normalizes rotted content, incoherence, and contradictory facts across web surfaces, and acts as a provider-agnostic mold compiler for AI surfaces (OpenAI Plugins, Custom GPTs, Claude Skills, Gemini Gems, CF MCP Portals, ChittyOS Skins). + +--- + +## 2. The 6-Stage Dynamic Nutrient Pipeline + +``` +STAGE 1 STAGE 2 STAGE 3 STAGE 4 STAGE 5 STAGE 6 +INGEST → COMPOST → STORE → REASSEMBLE → HOT-LOAD → VERIFY +Raw Material Elemental Canonical Provider Live API Health check +(URLs/Docs) Nutrients Atoms (D1) Molds Activation & Rollback +``` + +### Stage 1: Ingest +- Accepts raw web URLs, OpenAPI specs, REST docs, markdown, PDFs, or tool definitions. +- Interfaces via Firecrawl AI Scraper (`chittyscrape/src/targets/firecrawl.ts`) feeding `DriveIngestWorkflow.ts` (`chittystorage`). + +### Stage 2: Compost (Atomization) +- Breaks composite inputs into elemental reusable nutrients (tool specs, claims, prompts, auth credentials, knowledge chunks). +- Preserves atomicity: an item is elemental when further decomposition destroys meaning. + +### Stage 3: Canonical Nutrient Store +- Stores atoms canonically in Cloudflare D1 (`chittyevidence-db`) using `wm_*` tables: + - `wm_pages`: Scraped web page metadata and content hashes. + - `wm_claims`: Extracted factual claims. + - `wm_contradictions`: Cross-source divergence & contradiction scores. + - `wm_flags`: User-submitted incoherence reports. + - `wm_rewards`: User point economy transactions. + +### Stage 4: Reassemble +- Selects canonical atoms and packs them into provider-native composite bundles ("skins") using provider-specific templates. + +### Stage 5: Hot Load +- Pushes assembled bundles to provider registration APIs dynamically without manual steps or downtime: + - CF MCP Portal: `POST /accounts/{id}/mcp/servers` + - OpenAI Responses API: `{ type: "mcp", server_url }` + - Custom GPTs: OpenAPI 3.1 Actions + - Claude Skills: `.well-known/skills/index.json` + +### Stage 6: Verify & Rollback +- Executes automated post-activation health checks. On failure, triggers immediate automatic rollback to the prior working bundle version. + +--- + +## 3. Worker Substrate & Placement + +- **Host VM:** `chittyserv-vm` (`100.86.86.0`) under `/home/ubuntu/projects/github.com/CHITTYOS/` +- **Worker Package:** `chittyentity/workers/chittyagent-webmaster` +- **DO Class:** `WebmasterAgent` extending `McpAgent` diff --git a/scripts/generate-marketplace.sh b/scripts/generate-marketplace.sh index 0357f9d..f52c09b 100755 --- a/scripts/generate-marketplace.sh +++ b/scripts/generate-marketplace.sh @@ -28,6 +28,7 @@ CATEGORY_MAP[chittyos-core]="ecosystem" CATEGORY_MAP[chittyos-devops]="operations" CATEGORY_MAP[chittyos-legal]="legal" CATEGORY_MAP[chittyos-governance]="security" +CATEGORY_MAP[chittyos-security]="security" CATEGORY_MAP[chittyos-proxy-agents]="integrations" CATEGORY_MAP[chittymarket-manager]="ecosystem" CATEGORY_MAP[chittyos-mcp]="ecosystem" @@ -39,6 +40,7 @@ KEYWORDS_MAP[chittyos-core]="chittyos,session,context,agents,schema,canon" KEYWORDS_MAP[chittyos-devops]="deploy,health,registry,pipelines,wrangler,compliance" KEYWORDS_MAP[chittyos-legal]="legal,evidence,disputes,docket,cases,custody" KEYWORDS_MAP[chittyos-governance]="governance,hooks,entity-types,chittyid,deploy-gate,schema" +KEYWORDS_MAP[chittyos-security]="security,threat-model,cloudflare,workers,mcp,secrets,compliance" KEYWORDS_MAP[chittyos-proxy-agents]="notion,chatgpt,cloudflare,proxy,agent" KEYWORDS_MAP[chittymarket-manager]="marketplace,market,artifacts,toggle,manage" # nowebmaster was absent from this map, so regeneration emitted keywords: []