chore: remove ContentTwin product health-check workflow - #1273
Conversation
|
You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard. |
|
Warning Review limit reached
Next review available in: 55 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (9)
📝 WalkthroughWalkthroughThe ContentTwin audit workflow, script, documentation, and scenarios were removed. Workflow triggers and validation were updated, and repository documentation replaced the audit listing with other scheduled reports. ChangesContentTwin audit removal
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
Suggested labels: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ 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 |
There was a problem hiding this comment.
Code Review
This pull request completely removes the content-twin-audit workflow and all of its associated assets from the repository. This includes deleting the audit script, the scenario specifications, and the workflow documentation, as well as cleaning up references to this workflow in .github/copilot-instructions.md, README.md, profile/README.md, and tests/aw/validate-specs.sh. There are no review comments, and I have no feedback to provide.
There was a problem hiding this comment.
Pull request overview
This PR removes the product-specific content-twin-audit health-check automation from .github-private, keeping this repo focused on org-wide CI/automation infrastructure rather than monitoring a single product repository.
Changes:
- Deleted the
content-twin-auditscheduled workflow and its supporting audit script. - Removed the workflow’s documentation + scenario spec, and de-registered it from AW validation.
- Cleaned up indexes/wiring (workflow test job paths + ShellCheck list, README workflow tables, Copilot instructions project tree).
Reviewed changes
Copilot reviewed 9 out of 9 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
tests/aw/validate-specs.sh |
Removes content-twin-audit from the validated AW workflow list. |
tests/aw/content-twin-audit/scenarios.md |
Deletes the scenario spec for the removed workflow. |
scripts/aw-content-twin-audit.sh |
Deletes the audit implementation script. |
README.md |
Removes the workflow from the scheduled workflows index table. |
profile/README.md |
Removes the workflow from the public profile’s scheduled workflows index table. |
docs/aw/content-twin-audit.md |
Deletes the operational documentation for the removed workflow. |
.github/workflows/test-aw.yml |
Removes the workflow from path triggers and from the ShellCheck list. |
.github/workflows/content-twin-audit.yml |
Deletes the scheduled workflow itself. |
.github/copilot-instructions.md |
Removes references to the deleted workflow from repo description + project tree. |
The `content-twin-audit.yml` gh-aw workflow is a product-specific pipeline health check for the `petry-projects/ContentTwin` repo (content freshness, queue depth, publish.yml failures). That kind of product monitoring does not belong in `.github-private`, which is the org's CI/automation infrastructure repo. Its signals are meaningful only for a content-publishing pipeline and do not generalize; the org-wide hygiene needs (docs, deps, standards) are already covered by the generic sibling workflows that shipped in the same PR (#303). Removes the workflow, its script, doc, and test scenarios, and de-lists it from test-aw.yml, validate-specs.sh, copilot-instructions.md, and the two README workflow indexes. Leaves every reference to ContentTwin-the-product repo (release rings, deploy targets, pr-review consumers) untouched. Verified content-twin-audit was the only product-scoped health check; all other scheduled workflows target org-infrastructure repos or are generic. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
676d96d to
644b3d5
Compare
Dev-Lead — waiting on PR blockers (intent: review-changes)PR: #1273 |
|
Note @don-petry I reviewed this PR and no code changes were needed, but it still has blocking checks or reviews (failing or cancelled checks, or changes-requested reviews), so I cannot mark it done yet. I'll re-check automatically. |
|
Dev-Lead — fix-bot-comment (no-changes)Agent reasoning |
donpetry-bot
left a comment
There was a problem hiding this comment.
Automated review — APPROVED ✓
Risk: MEDIUM
Reviewed commit: 644b3d56865fcf4cdec17d4b512de651dc9695f4
Review mode: triage-approved (single reviewer)
Summary
Confirms the triage assessment: this PR cleanly removes the product-specific content-twin-audit gh-aw workflow (workflow YAML, audit script, docs, test spec) and de-lists it from all 5 wiring points (test-aw.yml, validate-specs.sh, copilot-instructions.md, both READMEs). The change is purely subtractive — only 2 added lines, both doc prose. A grep of the PR head SHA finds zero leftover references to the deleted workflow, script, or its config vars, while ContentTwin-the-product references (release registry, deploy targets) are correctly left untouched as stated in the PR body. Removing it reduces secret surface (drops a scheduled consumer of DON_PETRY_BOT_GH_PAT and CLAUDE_CODE_OAUTH_TOKEN).
Linked issue analysis
No linked issues. The PR body provides a thorough standalone rationale: the workflow was product-specific pipeline monitoring that does not belong in the org's CI-infrastructure repo, and org-wide hygiene remains covered by the generic sibling workflows (docs-health-check, dependency-advisory, standards-sync).
Findings
No blocking findings.
- Completeness: verified via grep at head SHA
644b3d5— no dangling references tocontent-twin-audit,aw-content-twin-audit.sh, or its vars (CONTENT_STALE_DAYS,CONTENT_TWIN_PUBLISH_WORKFLOW) remain anywhere in the tree. - Test deletion:
tests/aw/content-twin-audit/scenarios.mddeleted alongside its workflow; acknowledged via theack-test-deletionlabel, andValidate AW specspasses with the entry removed from theWORKFLOWSarray. - Standards: no thin caller stubs touched (
caller-stub-freezegreen);test-aw.ymledits only remove the deleted entries. - Secret scan:
run_secret_scanningMCP tool unavailable in this session; gitleaks CI check passed and the diff adds no secret-bearing content. - Bot reviews: CodeRabbit approved; Gemini and Copilot left comment-only reviews with no unresolved threads.
CI status
All required checks pass (CodeQL, SonarCloud, agent-shield, dependency-audit). All code-validation checks green: lint, shellcheck (×3), actionlint, bats, unit-tests, gh-aw-compile, AW spec validation, gitleaks, CodeQL analyze, Agent Security Scan, template-drift, caller-stub-freeze, holdout-guard. The only non-green entries are two cancelled non-required dev-lead automation jobs (the org's autonomous agent run, superseded — its comment at this SHA confirms it completed with no changes needed).
Reviewed automatically by the PR-review agent (single-reviewer mode: fable 5). Reply if you need a human review.
The `content-twin-audit.yml` gh-aw workflow is a product-specific pipeline health check for the `petry-projects/ContentTwin` repo (content freshness, queue depth, publish.yml failures). That kind of product monitoring does not belong in `.github-private`, which is the org's CI/automation infrastructure repo. Its signals are meaningful only for a content-publishing pipeline and do not generalize; the org-wide hygiene needs (docs, deps, standards) are already covered by the generic sibling workflows that shipped in the same PR (#303). Removes the workflow, its script, doc, and test scenarios, and de-lists it from test-aw.yml, validate-specs.sh, copilot-instructions.md, and the two README workflow indexes. Leaves every reference to ContentTwin-the-product repo (release rings, deploy targets, pr-review consumers) untouched. Verified content-twin-audit was the only product-scoped health check; all other scheduled workflows target org-infrastructure repos or are generic. Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The `content-twin-audit.yml` gh-aw workflow is a product-specific pipeline health check for the `petry-projects/ContentTwin` repo (content freshness, queue depth, publish.yml failures). That kind of product monitoring does not belong in `.github-private`, which is the org's CI/automation infrastructure repo. Its signals are meaningful only for a content-publishing pipeline and do not generalize; the org-wide hygiene needs (docs, deps, standards) are already covered by the generic sibling workflows that shipped in the same PR (#303). Removes the workflow, its script, doc, and test scenarios, and de-lists it from test-aw.yml, validate-specs.sh, copilot-instructions.md, and the two README workflow indexes. Leaves every reference to ContentTwin-the-product repo (release rings, deploy targets, pr-review consumers) untouched. Verified content-twin-audit was the only product-scoped health check; all other scheduled workflows target org-infrastructure repos or are generic. Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The `content-twin-audit.yml` gh-aw workflow is a product-specific pipeline health check for the `petry-projects/ContentTwin` repo (content freshness, queue depth, publish.yml failures). That kind of product monitoring does not belong in `.github-private`, which is the org's CI/automation infrastructure repo. Its signals are meaningful only for a content-publishing pipeline and do not generalize; the org-wide hygiene needs (docs, deps, standards) are already covered by the generic sibling workflows that shipped in the same PR (#303). Removes the workflow, its script, doc, and test scenarios, and de-lists it from test-aw.yml, validate-specs.sh, copilot-instructions.md, and the two README workflow indexes. Leaves every reference to ContentTwin-the-product repo (release rings, deploy targets, pr-review consumers) untouched. Verified content-twin-audit was the only product-scoped health check; all other scheduled workflows target org-infrastructure repos or are generic. Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The `content-twin-audit.yml` gh-aw workflow is a product-specific pipeline health check for the `petry-projects/ContentTwin` repo (content freshness, queue depth, publish.yml failures). That kind of product monitoring does not belong in `.github-private`, which is the org's CI/automation infrastructure repo. Its signals are meaningful only for a content-publishing pipeline and do not generalize; the org-wide hygiene needs (docs, deps, standards) are already covered by the generic sibling workflows that shipped in the same PR (#303). Removes the workflow, its script, doc, and test scenarios, and de-lists it from test-aw.yml, validate-specs.sh, copilot-instructions.md, and the two README workflow indexes. Leaves every reference to ContentTwin-the-product repo (release rings, deploy targets, pr-review consumers) untouched. Verified content-twin-audit was the only product-scoped health check; all other scheduled workflows target org-infrastructure repos or are generic. Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The `content-twin-audit.yml` gh-aw workflow is a product-specific pipeline health check for the `petry-projects/ContentTwin` repo (content freshness, queue depth, publish.yml failures). That kind of product monitoring does not belong in `.github-private`, which is the org's CI/automation infrastructure repo. Its signals are meaningful only for a content-publishing pipeline and do not generalize; the org-wide hygiene needs (docs, deps, standards) are already covered by the generic sibling workflows that shipped in the same PR (#303). Removes the workflow, its script, doc, and test scenarios, and de-lists it from test-aw.yml, validate-specs.sh, copilot-instructions.md, and the two README workflow indexes. Leaves every reference to ContentTwin-the-product repo (release rings, deploy targets, pr-review consumers) untouched. Verified content-twin-audit was the only product-scoped health check; all other scheduled workflows target org-infrastructure repos or are generic. Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The `content-twin-audit.yml` gh-aw workflow is a product-specific pipeline health check for the `petry-projects/ContentTwin` repo (content freshness, queue depth, publish.yml failures). That kind of product monitoring does not belong in `.github-private`, which is the org's CI/automation infrastructure repo. Its signals are meaningful only for a content-publishing pipeline and do not generalize; the org-wide hygiene needs (docs, deps, standards) are already covered by the generic sibling workflows that shipped in the same PR (#303). Removes the workflow, its script, doc, and test scenarios, and de-lists it from test-aw.yml, validate-specs.sh, copilot-instructions.md, and the two README workflow indexes. Leaves every reference to ContentTwin-the-product repo (release rings, deploy targets, pr-review consumers) untouched. Verified content-twin-audit was the only product-scoped health check; all other scheduled workflows target org-infrastructure repos or are generic. Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The `content-twin-audit.yml` gh-aw workflow is a product-specific pipeline health check for the `petry-projects/ContentTwin` repo (content freshness, queue depth, publish.yml failures). That kind of product monitoring does not belong in `.github-private`, which is the org's CI/automation infrastructure repo. Its signals are meaningful only for a content-publishing pipeline and do not generalize; the org-wide hygiene needs (docs, deps, standards) are already covered by the generic sibling workflows that shipped in the same PR (#303). Removes the workflow, its script, doc, and test scenarios, and de-lists it from test-aw.yml, validate-specs.sh, copilot-instructions.md, and the two README workflow indexes. Leaves every reference to ContentTwin-the-product repo (release rings, deploy targets, pr-review consumers) untouched. Verified content-twin-audit was the only product-scoped health check; all other scheduled workflows target org-infrastructure repos or are generic. Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The `content-twin-audit.yml` gh-aw workflow is a product-specific pipeline health check for the `petry-projects/ContentTwin` repo (content freshness, queue depth, publish.yml failures). That kind of product monitoring does not belong in `.github-private`, which is the org's CI/automation infrastructure repo. Its signals are meaningful only for a content-publishing pipeline and do not generalize; the org-wide hygiene needs (docs, deps, standards) are already covered by the generic sibling workflows that shipped in the same PR (#303). Removes the workflow, its script, doc, and test scenarios, and de-lists it from test-aw.yml, validate-specs.sh, copilot-instructions.md, and the two README workflow indexes. Leaves every reference to ContentTwin-the-product repo (release rings, deploy targets, pr-review consumers) untouched. Verified content-twin-audit was the only product-scoped health check; all other scheduled workflows target org-infrastructure repos or are generic. Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The `content-twin-audit.yml` gh-aw workflow is a product-specific pipeline health check for the `petry-projects/ContentTwin` repo (content freshness, queue depth, publish.yml failures). That kind of product monitoring does not belong in `.github-private`, which is the org's CI/automation infrastructure repo. Its signals are meaningful only for a content-publishing pipeline and do not generalize; the org-wide hygiene needs (docs, deps, standards) are already covered by the generic sibling workflows that shipped in the same PR (#303). Removes the workflow, its script, doc, and test scenarios, and de-lists it from test-aw.yml, validate-specs.sh, copilot-instructions.md, and the two README workflow indexes. Leaves every reference to ContentTwin-the-product repo (release rings, deploy targets, pr-review consumers) untouched. Verified content-twin-audit was the only product-scoped health check; all other scheduled workflows target org-infrastructure repos or are generic. Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The `content-twin-audit.yml` gh-aw workflow is a product-specific pipeline health check for the `petry-projects/ContentTwin` repo (content freshness, queue depth, publish.yml failures). That kind of product monitoring does not belong in `.github-private`, which is the org's CI/automation infrastructure repo. Its signals are meaningful only for a content-publishing pipeline and do not generalize; the org-wide hygiene needs (docs, deps, standards) are already covered by the generic sibling workflows that shipped in the same PR (#303). Removes the workflow, its script, doc, and test scenarios, and de-lists it from test-aw.yml, validate-specs.sh, copilot-instructions.md, and the two README workflow indexes. Leaves every reference to ContentTwin-the-product repo (release rings, deploy targets, pr-review consumers) untouched. Verified content-twin-audit was the only product-scoped health check; all other scheduled workflows target org-infrastructure repos or are generic. Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The `content-twin-audit.yml` gh-aw workflow is a product-specific pipeline health check for the `petry-projects/ContentTwin` repo (content freshness, queue depth, publish.yml failures). That kind of product monitoring does not belong in `.github-private`, which is the org's CI/automation infrastructure repo. Its signals are meaningful only for a content-publishing pipeline and do not generalize; the org-wide hygiene needs (docs, deps, standards) are already covered by the generic sibling workflows that shipped in the same PR (#303). Removes the workflow, its script, doc, and test scenarios, and de-lists it from test-aw.yml, validate-specs.sh, copilot-instructions.md, and the two README workflow indexes. Leaves every reference to ContentTwin-the-product repo (release rings, deploy targets, pr-review consumers) untouched. Verified content-twin-audit was the only product-scoped health check; all other scheduled workflows target org-infrastructure repos or are generic. Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The `content-twin-audit.yml` gh-aw workflow is a product-specific pipeline health check for the `petry-projects/ContentTwin` repo (content freshness, queue depth, publish.yml failures). That kind of product monitoring does not belong in `.github-private`, which is the org's CI/automation infrastructure repo. Its signals are meaningful only for a content-publishing pipeline and do not generalize; the org-wide hygiene needs (docs, deps, standards) are already covered by the generic sibling workflows that shipped in the same PR (#303). Removes the workflow, its script, doc, and test scenarios, and de-lists it from test-aw.yml, validate-specs.sh, copilot-instructions.md, and the two README workflow indexes. Leaves every reference to ContentTwin-the-product repo (release rings, deploy targets, pr-review consumers) untouched. Verified content-twin-audit was the only product-scoped health check; all other scheduled workflows target org-infrastructure repos or are generic. Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The `content-twin-audit.yml` gh-aw workflow is a product-specific pipeline health check for the `petry-projects/ContentTwin` repo (content freshness, queue depth, publish.yml failures). That kind of product monitoring does not belong in `.github-private`, which is the org's CI/automation infrastructure repo. Its signals are meaningful only for a content-publishing pipeline and do not generalize; the org-wide hygiene needs (docs, deps, standards) are already covered by the generic sibling workflows that shipped in the same PR (#303). Removes the workflow, its script, doc, and test scenarios, and de-lists it from test-aw.yml, validate-specs.sh, copilot-instructions.md, and the two README workflow indexes. Leaves every reference to ContentTwin-the-product repo (release rings, deploy targets, pr-review consumers) untouched. Verified content-twin-audit was the only product-scoped health check; all other scheduled workflows target org-infrastructure repos or are generic. Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The `content-twin-audit.yml` gh-aw workflow is a product-specific pipeline health check for the `petry-projects/ContentTwin` repo (content freshness, queue depth, publish.yml failures). That kind of product monitoring does not belong in `.github-private`, which is the org's CI/automation infrastructure repo. Its signals are meaningful only for a content-publishing pipeline and do not generalize; the org-wide hygiene needs (docs, deps, standards) are already covered by the generic sibling workflows that shipped in the same PR (#303). Removes the workflow, its script, doc, and test scenarios, and de-lists it from test-aw.yml, validate-specs.sh, copilot-instructions.md, and the two README workflow indexes. Leaves every reference to ContentTwin-the-product repo (release rings, deploy targets, pr-review consumers) untouched. Verified content-twin-audit was the only product-scoped health check; all other scheduled workflows target org-infrastructure repos or are generic. Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The `content-twin-audit.yml` gh-aw workflow is a product-specific pipeline health check for the `petry-projects/ContentTwin` repo (content freshness, queue depth, publish.yml failures). That kind of product monitoring does not belong in `.github-private`, which is the org's CI/automation infrastructure repo. Its signals are meaningful only for a content-publishing pipeline and do not generalize; the org-wide hygiene needs (docs, deps, standards) are already covered by the generic sibling workflows that shipped in the same PR (#303). Removes the workflow, its script, doc, and test scenarios, and de-lists it from test-aw.yml, validate-specs.sh, copilot-instructions.md, and the two README workflow indexes. Leaves every reference to ContentTwin-the-product repo (release rings, deploy targets, pr-review consumers) untouched. Verified content-twin-audit was the only product-scoped health check; all other scheduled workflows target org-infrastructure repos or are generic. Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The `content-twin-audit.yml` gh-aw workflow is a product-specific pipeline health check for the `petry-projects/ContentTwin` repo (content freshness, queue depth, publish.yml failures). That kind of product monitoring does not belong in `.github-private`, which is the org's CI/automation infrastructure repo. Its signals are meaningful only for a content-publishing pipeline and do not generalize; the org-wide hygiene needs (docs, deps, standards) are already covered by the generic sibling workflows that shipped in the same PR (#303). Removes the workflow, its script, doc, and test scenarios, and de-lists it from test-aw.yml, validate-specs.sh, copilot-instructions.md, and the two README workflow indexes. Leaves every reference to ContentTwin-the-product repo (release rings, deploy targets, pr-review consumers) untouched. Verified content-twin-audit was the only product-scoped health check; all other scheduled workflows target org-infrastructure repos or are generic. Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The `content-twin-audit.yml` gh-aw workflow is a product-specific pipeline health check for the `petry-projects/ContentTwin` repo (content freshness, queue depth, publish.yml failures). That kind of product monitoring does not belong in `.github-private`, which is the org's CI/automation infrastructure repo. Its signals are meaningful only for a content-publishing pipeline and do not generalize; the org-wide hygiene needs (docs, deps, standards) are already covered by the generic sibling workflows that shipped in the same PR (#303). Removes the workflow, its script, doc, and test scenarios, and de-lists it from test-aw.yml, validate-specs.sh, copilot-instructions.md, and the two README workflow indexes. Leaves every reference to ContentTwin-the-product repo (release rings, deploy targets, pr-review consumers) untouched. Verified content-twin-audit was the only product-scoped health check; all other scheduled workflows target org-infrastructure repos or are generic. Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
The `content-twin-audit.yml` gh-aw workflow is a product-specific pipeline health check for the `petry-projects/ContentTwin` repo (content freshness, queue depth, publish.yml failures). That kind of product monitoring does not belong in `.github-private`, which is the org's CI/automation infrastructure repo. Its signals are meaningful only for a content-publishing pipeline and do not generalize; the org-wide hygiene needs (docs, deps, standards) are already covered by the generic sibling workflows that shipped in the same PR (#303). Removes the workflow, its script, doc, and test scenarios, and de-lists it from test-aw.yml, validate-specs.sh, copilot-instructions.md, and the two README workflow indexes. Leaves every reference to ContentTwin-the-product repo (release rings, deploy targets, pr-review consumers) untouched. Verified content-twin-audit was the only product-scoped health check; all other scheduled workflows target org-infrastructure repos or are generic. Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>



What
Removes the
content-twin-audit.ymlgh-aw workflow and all of its wiring.Deleted (4 files):
.github/workflows/content-twin-audit.yml— the scheduled workflowscripts/aw-content-twin-audit.sh— the audit logicdocs/aw/content-twin-audit.md— its documentationtests/aw/content-twin-audit/scenarios.md— its test specDe-listed (5 files):
.github/workflows/test-aw.yml— removed the path trigger + shellcheck entrytests/aw/validate-specs.sh— removed from theWORKFLOWSvalidation array.github/copilot-instructions.md— removed both mentions (prose + project tree)README.md/profile/README.md— removed the workflow-index rowsWhy
content-twin-audit.ymlis a product-specific pipeline health check for thepetry-projects/ContentTwinrepo — it flags stale content, an empty contentqueue/, andpublish.ymlfailures. Those signals are meaningful only for acontent-publishing pipeline and don't generalize to any other repo (7 days of no
commits is a failure for a content app, but healthy for a stable library).
That kind of product monitoring doesn't belong in
.github-private, which isthe org's CI/automation infrastructure repo. The genuinely org-wide hygiene
needs — docs, dependencies, standards drift — are already covered by the generic
sibling workflows (
docs-health-check,dependency-advisory,standards-sync)that shipped in the same original PR (#303). This one was the odd product-scoped
member of that batch.
Scope / safety
ContentTwin-the-product reference untouched — release rings(
release/registry.yml), deploy targets, pr-review consumer lists, dev-leadrepo loops, and the
profile/README.mdproduct listing. Those are about theorg managing that repo, not about the health check.
workflows: every other target-repo variable points at org-infrastructure repos
(
.github-private,.github) or is generically parameterized (target_repodefaulting to self). No workflow hardcodes any product repo.
Verification
tests/aw/validate-specs.sh: 30 passed, 0 failed after removalshellcheckon remainingaw-*.shscripts: clean🤖 Generated with Claude Code
Summary by CodeRabbit
Removed Features
Documentation
Maintenance