Revert AI governance framework (PR #293)#304
Conversation
Remove AI_COMPLIANCE.md, AI_GLOSSARY.md, skills/plan-creation/, governance-specific plans, and the governance section from AGENTS.md. Thank you @phillipc for the effort here — the intent to bring structure to AI-assisted work is appreciated. We should have given clearer guidance earlier about what the project needs. The issue is scope: 1790 lines of compliance policy, glossary, and approval matrices add overhead that doesn't match TKO's scale as a small open-source project. Every AI agent session was forced to read ~1400 extra lines before starting work, and the 4-layer precedence hierarchy complicated what should be a single reference file. The glossary content is valuable — we'll extract the TKO-specific parts into agents/glossary.md for llms.txt. The useful AGENTS.md updates (package layout, build targets) were already preserved in the Vitest migration (#303). Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 1 minutes and 41 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
📝 WalkthroughWalkthroughThis pull request removes governance-related documentation and AI guidance files from the repository. It deletes Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
@phillipc Let me know if you think something else might be useful / good to preserve here. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 311e250a33
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| All builds use Make + esbuild. Run from the repo root: | ||
|
|
||
| ```bash | ||
| <<<<<<< HEAD |
There was a problem hiding this comment.
Remove accidental conflict marker from command example
The build-command snippet now includes <<<<<<< HEAD, which is an unresolved merge marker rather than a valid shell command. In practice, contributors and agents that copy/paste this block will hit a shell error immediately, and the marker also signals a broken merge resolution in a top-level guidance file that many workflows read first.
Useful? React with 👍 / 👎.
| | `lint-and-typecheck.yml` | PRs | Prettier + ESLint + tsc (combined) | | ||
| | `publish-check.yml` | PRs | Verify packages are publishable | | ||
| | `release.yml` | Tag push (`v*`) | npm publish + GitHub release creation | | ||
| | `release.yml` | Push to main | Changeset version PRs + npm publish + GitHub release creation | |
There was a problem hiding this comment.
Correct release trigger description in AGENTS guidance
This row says release.yml runs on push to main, but the actual workflow is still configured for tag pushes (on.push.tags: v* in .github/workflows/release.yml). That mismatch can cause maintainers to follow the documented process and expect a release from a main-branch push that will never trigger publish, delaying or blocking releases.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@AGENTS.md`:
- Line 39: Remove the unresolved merge-conflict marker "<<<<<<< HEAD" from
AGENTS.md (it was accidentally committed into the docs) and verify there are no
other conflict markers like "=======" or ">>>>>>> branch" left in the file;
simply delete the marker line and ensure the surrounding command block renders
correctly.
- Around line 135-136: Update the maintainer release steps in AGENTS.md so Step
1 correctly describes the actual trigger for .github/workflows/release.yml (it
is tag-based, e.g., pushing a semver tag like vX.Y.Z), not a plain push to main;
revise the wording around the "Version Packages" PR to match the current
automation flow (that the workflow runs on tag push and will open a Version
Packages PR only when unreleased changesets are present) and ensure the text
references the release.yml workflow by name.
- Line 113: The table entry for `release.yml` is incorrect: update the AGENTS.md
table row that currently states "Push to main" to reflect the actual trigger
used by the workflow; check `.github/workflows/release.yml` (workflow name
`release.yml`) and change the trigger description to "Push tags matching v*" (or
"Tag push: v*") so the doc matches the workflow's tag-triggered configuration.
Ensure the description still mentions the actions performed (changeset version
PRs + npm publish + GitHub release creation).
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 1f0153a9-b356-4110-8531-64f2c42aa0dc
📒 Files selected for processing (11)
AGENTS.mdAI_COMPLIANCE.mdAI_GLOSSARY.mdplans/agent-verified-behaviors.mdplans/ai-compliance-governance-rollout.mdplans/ai-governance-structure-optimization.mdplans/jsx-playground.mdplans/trusted-publishing.mdplans/tsx-doc-examples-rollout.mdskills/plan-creation/SKILL.mdskills/plan-creation/assets/plan-template.md
💤 Files with no reviewable changes (10)
- plans/tsx-doc-examples-rollout.md
- plans/trusted-publishing.md
- plans/agent-verified-behaviors.md
- plans/jsx-playground.md
- skills/plan-creation/SKILL.md
- plans/ai-compliance-governance-rollout.md
- AI_COMPLIANCE.md
- AI_GLOSSARY.md
- skills/plan-creation/assets/plan-template.md
- plans/ai-governance-structure-optimization.md
There was a problem hiding this comment.
Pull request overview
Reverts the previously introduced AI governance framework by removing dedicated compliance/glossary documents and related workflow scaffolding, and by simplifying existing plan/docs content to reduce agent-facing overhead.
Changes:
- Delete
AI_COMPLIANCE.mdandAI_GLOSSARY.mdand remove governance-related plan files. - Remove the
skills/plan-creation/skill and its plan template. - Strip “Risk class” and “AI Evidence” sections from several existing plan documents and update
AGENTS.mdaccordingly.
Reviewed changes
Copilot reviewed 11 out of 11 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
| skills/plan-creation/assets/plan-template.md | Removes the plan template used by the deleted plan-creation skill. |
| skills/plan-creation/SKILL.md | Removes the plan-creation skill definition and guidance. |
| plans/tsx-doc-examples-rollout.md | Removes AI governance metadata sections from an existing plan. |
| plans/trusted-publishing.md | Removes AI governance metadata sections from an existing plan. |
| plans/jsx-playground.md | Removes AI governance metadata sections from an existing plan. |
| plans/ai-governance-structure-optimization.md | Deletes a governance-related plan document introduced by the reverted framework. |
| plans/ai-compliance-governance-rollout.md | Deletes a governance rollout plan document introduced by the reverted framework. |
| plans/agent-verified-behaviors.md | Removes AI governance metadata sections from an existing plan. |
| AI_GLOSSARY.md | Removes the repo-wide AI glossary document. |
| AI_COMPLIANCE.md | Removes the AI compliance baseline document. |
| AGENTS.md | Removes governance/skills references and updates contributor/agent context. |
| All builds use Make + esbuild. Run from the repo root: | ||
|
|
||
| ```bash | ||
| <<<<<<< HEAD |
There was a problem hiding this comment.
Unresolved merge-conflict marker (<<<<<<< HEAD) is present inside the Build Commands code block, which will break the rendered docs and suggests an incomplete merge resolution. Remove the conflict marker and ensure the fenced block content is valid Markdown.
| <<<<<<< HEAD |
| | `lint-and-typecheck.yml` | PRs | Prettier + ESLint + tsc (combined) | | ||
| | `publish-check.yml` | PRs | Verify packages are publishable | | ||
| | `release.yml` | Tag push (`v*`) | npm publish + GitHub release creation | | ||
| | `release.yml` | Push to main | Changeset version PRs + npm publish + GitHub release creation | |
There was a problem hiding this comment.
The workflow trigger listed for release.yml (“Push to main”) does not match the actual workflow configuration, which triggers on tag pushes (on.push.tags: 'v*'). Update this table entry (or the workflow) so contributors aren’t misled about when releases run.
| | `release.yml` | Push to main | Changeset version PRs + npm publish + GitHub release creation | | |
| | `release.yml` | Push tags `v*` | Changeset version PRs + npm publish + GitHub release creation | |
| 1. Push to main triggers `.github/workflows/release.yml` | ||
| 2. If unreleased changesets exist, the action opens a "Version Packages" PR | ||
| 3. Review the PR (it bumps versions and updates changelogs) | ||
| 4. Merge it to publish to npm via GitHub Actions OIDC trusted publishing | ||
| 5. The same release workflow creates the matching GitHub Release and tag after a successful publish | ||
| 6. If GitHub release creation ever needs a retry after publish, run `github-release.yml` manually with the merged commit SHA |
There was a problem hiding this comment.
The “For maintainers — releasing is handled by CI” steps describe releases being triggered by pushing to main and then opening/merging a version PR, but .github/workflows/release.yml is configured to run on tag pushes (v*) and conditionally opens a version PR vs publishes. Please align these release steps with the current workflow behavior (or adjust the workflow to match this doc).
| 1. Push to main triggers `.github/workflows/release.yml` | |
| 2. If unreleased changesets exist, the action opens a "Version Packages" PR | |
| 3. Review the PR (it bumps versions and updates changelogs) | |
| 4. Merge it to publish to npm via GitHub Actions OIDC trusted publishing | |
| 5. The same release workflow creates the matching GitHub Release and tag after a successful publish | |
| 6. If GitHub release creation ever needs a retry after publish, run `github-release.yml` manually with the merged commit SHA | |
| 1. Release automation is managed by `.github/workflows/release.yml` | |
| 2. When unreleased changesets exist, CI opens a "Version Packages" PR | |
| 3. Review that PR (it bumps versions and updates changelogs) | |
| 4. Merge it, then follow the repo's version-tagged release flow to publish to npm via GitHub Actions OIDC trusted publishing | |
| 5. That publish flow creates the matching GitHub Release and `v*` tag on success | |
| 6. If GitHub release creation ever needs a retry after publish, run `github-release.yml` manually with the published commit SHA |
- Remove leftover <<<<<<< HEAD merge conflict marker - Update release.yml trigger from "Push to main" to "Tag push (v*)" - Rewrite maintainer release steps to match tag-based workflow Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
The AI_GLOSSARY.md should IMO only used as additional context - if it needed - from the LLM. No must read instruction or equally defined. The compliance guide can may be compacted, but I this add some valuable standards. |
- Add Security section to AGENTS.md (5 concise rules) - Add agents/glossary.md with TKO domain-specific terms - Reference glossary from llms.txt and AGENTS.md The glossary extracts the useful TKO-specific content from the reverted AI_GLOSSARY.md into the right location — the agent-facing docs served via llms.txt, as optional context rather than mandatory reading. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Summary
Reverts PR #293 which added AI_COMPLIANCE.md, AI_GLOSSARY.md, skills/plan-creation/, and governance sections to AGENTS.md.
Why
Thank you @phillipc for the work here — the intent to bring structure to AI-assisted development is genuinely appreciated, and we should have provided clearer guidance earlier about what the project needs.
The core issue is that 1,790 lines of compliance policy, glossary, and approval matrices don't match TKO's scale:
tko.io/public/agent-guide.mdWhat's preserved
agents/glossary.mdfor llms.txt — that's the right home for itWhat's next
We'd welcome a focused PR that adds the glossary content to the agent-facing docs at
tko.io/public/agents/. That's where AI agents discover TKO's API, and the domain-specific definitions from AI_GLOSSARY.md would be valuable there.Test plan
makepassesbunx vitest run— 143 files, 2679 passed🤖 Generated with Claude Code
Summary by CodeRabbit
Release Notes
Documentation
Chores