fix(twins): add one-off scripts for twins-post migration data

[AriaEdo]

Summary

• Add scripts/fix-twins-post-topics.js to reconnect orphaned topics relations left by the original twins-post migration (bare documentId arrays weren't handled correctly by the document service)
• Add scripts/republish-twins-post.js to republish posts whose published version is missing topics/blocks/cover relations
• Add scripts/grant-twins-public-permissions.js to grant the public role read access to twins-post/topic so twins-in-the-loop can query them without a token

Test plan

• Run each script against a local/staging Strapi instance and confirm topics/relations are correctly linked
• Verify public GraphQL queries for twins-post/topic succeed without auth after running the permissions script

🤖 Generated with Claude Code

[Copilot]

🟡 Changes recommended

The scripts currently appear to reference uncommitted/missing content-type UIDs in this repo and include a risky full join-table delete that could cause unintended data loss.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Pull request overview

This PR adds three one-off operational scripts intended to repair data inconsistencies introduced by the earlier twins-post migration and to make twins-post / topic readable by the public role for unauthenticated GraphQL consumption.

Changes:

• Add a republish script to re-sync published twins-post versions from their drafts.
• Add a topics-relinking script to reconnect twins-post ↔ topic relations using connect.
• Add a permissions script to grant the public role read permissions for the relevant content types.

File summaries

File	Description
scripts/republish-twins-post.js	Republishes all draft twins-post documents to fix missing relations in the published version.
scripts/grant-twins-public-permissions.js	Grants public-role read permissions for twins-post and topic actions.
scripts/fix-twins-post-topics.js	Clears/repairs broken topic relations for a fixed set of post slugs and topic slugs.

Review details

Suppressed comments (4)

scripts/republish-twins-post.js:28

• If any step in this script throws (e.g., during republishAll), the Strapi instance is never destroyed, which can leave DB connections open and make repeated runs flaky. Wrap the work in a try/finally that always calls app.destroy(), and move process.exit handling to the main() caller.

async function main() {
  const { createStrapi, compileStrapi } = require('@strapi/strapi');

  const appContext = await compileStrapi();
  const app = await createStrapi(appContext).load();

scripts/grant-twins-public-permissions.js:44

• If any step in this script throws (e.g., permission create), the Strapi instance is never destroyed, which can leave DB connections open. Use try/finally to always call app.destroy(), and handle process.exit from the main() caller.

async function main() {
  const { createStrapi, compileStrapi } = require('@strapi/strapi');

  const appContext = await compileStrapi();
  const app = await createStrapi(appContext).load();

scripts/fix-twins-post-topics.js:46

• This repo does not contain the content-type UID "api::twins-post.twins-post" outside these scripts (no committed src/api entries or other UID references), so these document-service calls will fail when running a local instance built from this codebase. Either commit the missing content-type definitions or update the UID(s) here to the ones actually present in the project.

      const post = await app.documents('api::twins-post.twins-post').findFirst({
        filters: { slug },
        status,
      });

scripts/fix-twins-post-topics.js:65

• If any step in this script throws, the Strapi instance is never destroyed, which can leave DB connections open. Wrap the work in try/finally and always call app.destroy(), then exit from the main() caller.

async function main() {
  const { createStrapi, compileStrapi } = require('@strapi/strapi');

  const appContext = await compileStrapi();
  const app = await createStrapi(appContext).load();

• Files reviewed: 3/3 changed files
• Comments generated: 4
• Review effort level: Lite

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[cla-assistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
1 out of 2 committers have signed the CLA.

✅ AriaEdo
❌ Copilot
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[cla-assistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
1 out of 2 committers have signed the CLA.

✅ AriaEdo
❌ Copilot
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[Copilot]

🟡 Changes recommended

The new scripts include behaviors that can unintentionally publish unpublished drafts and can delete more relation data than intended, creating a significant risk of data exposure/loss.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review details

Suppressed comments (2)

Previously missed (2) — in code that hasn't changed since the last review.

scripts/grant-twins-public-permissions.js:15

• These permission action strings reference api::twins-post.twins-post and api::topic.topic, but there are no corresponding content-type schemas for twins-post or topic anywhere under src/api in this repo (only article/author/category/global/roadmap). If the UIDs differ (or the types aren’t actually part of this codebase), the script will silently do nothing useful or fail at runtime—please confirm the correct UIDs for the target Strapi instance and update the action strings accordingly.
  scripts/republish-twins-post.js:21
• This script republishes every draft version it finds; in Strapi draft/publish this can inadvertently publish entries that were never previously published. The header comment says it should only fix entries that were already "published" but had a broken published version, so it should skip drafts that don’t have an existing published version.

• Files reviewed: 3/3 changed files
• Comments generated: 1
• Review effort level: Lite

[Copilot]

🔵 Needs a closer look

The republish and topics-fix scripts currently have concrete correctness/operational risks (draft-only content may be unintentionally published; and hard-coded UIDs appear to not exist in this repo), so they are not safe to run as-is.

Review details

Suppressed comments (4)

Previously missed (2) — in code that hasn't changed since the last review.

scripts/fix-twins-post-topics.js:6

• The header comment references migrate-twins-post.js, but that script isn’t present in this repository; that makes it unclear what migration introduced the orphaned rows. Consider rewording to refer to the “original twins-post migration” (or link the actual migration script/commit) instead of a non-existent path.

This issue also appears on line 32 of the same file.
scripts/republish-twins-post.js:6

• The header comment references migrate-twins-post.js, but that file isn’t present in this repository; this makes it harder to understand/trace the origin of the data issue when running the script later. Consider rewording to refer to the “original twins-post migration” (or link the actual migration script/commit) instead of a non-existent path.

This issue also appears on line 13 of the same file.

scripts/republish-twins-post.js:16

• findMany({ status: 'draft' }) will return only the first page by default and the loop will also publish drafts that currently have no published version, which can accidentally make draft-only content public. Consider (1) setting an explicit high limit (or paginating) and (2) skipping drafts that don’t already have a published version before calling publish.

async function republishAll(app) {
  const drafts = await app.documents(CONTENT_TYPE_UID).findMany({
    status: 'draft',
  });

scripts/fix-twins-post-topics.js:35

• This script hard-codes api::twins-post.twins-post and api::topic.topic, but those content types don’t exist in this codebase (only article, author, category, global, roadmap are defined under src/api/*). As-is, app.db.metadata.get('api::twins-post.twins-post') / app.documents('api::topic.topic') will fail when run from this repo; consider parameterizing the UIDs (like grant-twins-public-permissions.js does) or updating them to the actual content types used here.

async function fixTopics(app) {
  const topicsAttribute = app.db.metadata.get('api::twins-post.twins-post').attributes.topics;
  const joinTableName = topicsAttribute?.joinTable?.name;
  const postJoinColumn = topicsAttribute?.joinTable?.joinColumn?.name;

• Files reviewed: 3/3 changed files
• Comments generated: 0 new
• Review effort level: Lite

[Copilot]

🟡 Changes recommended

The new scripts include behaviors that can unintentionally publish unpublished drafts and can delete more relation data than intended, creating a significant risk of data...

Updated in 1d8977a to skip draft-only entries by checking for an existing published version before republishing. The content-type UID concern is already addressed on this branch by requiring explicit UIDs and validating that each one is registered before granting permissions (fba58ce).

[Copilot]

🔵 Needs a closer look

fix-twins-post-topics.js can currently crash with a TypeError due to unguarded metadata access, and republish-twins-post.js has a misleading twins-post naming/comment vs hard-coded api::article.article target.

Review details

Suppressed comments (2)

Previously missed (2) — in code that hasn't changed since the last review.

scripts/fix-twins-post-topics.js:33

• app.db.metadata.get('api::twins-post.twins-post') can return undefined when that content type UID isn’t registered in the current project (it isn’t present in this repo’s src/api). Accessing .attributes directly will throw a TypeError before the later join-table sanity check runs. Use optional chaining (or an explicit guard) so the script fails with the intended, actionable error message instead of crashing.
  scripts/republish-twins-post.js:12
• The script name and header comment refer to “twins-post”, but the actual UID is hard-coded to api::article.article. This mismatch makes it easy to run the script against the wrong content type (or misinterpret what it will mutate). Consider making the content-type UID an explicit CLI argument (with a safe default) and adjusting the header comment accordingly.

• Files reviewed: 3/3 changed files
• Comments generated: 0 new
• Review effort level: Lite

[Copilot]

🟡 Changes recommended

Critical data-safety and correctness issues remain in the repair and republish scripts.

Once you've addressed the issues Copilot identified, you can request another Copilot review.

Review details

Suppressed comments (1)

Previously missed (1) — in code that hasn't changed since the last review.

scripts/fix-twins-post-topics.js:71

• This success message is emitted even when neither version was found: both missing-version branches only warn and continue, then line 71 still says the post was linked. That can make an incomplete migration look successful; track which versions were actually updated and report partial/failure instead of unconditionally logging success.

• Files reviewed: 3/3 changed files
• Comments generated: 3
• Review effort level: Lite