docs: reconcile fork roadmap and release state

[OnlineChef]

Summary

Aligns the public roadmap and changelog with the repository's actual fork state.

Changes

• replace the inaccurate “all closed PRs merged” claim with integrated/reconciled branch work;
• distinguish prepared v1.0.0-alpha.1 metadata from an actually published release;
• correct the opencondex typo;
• rename “Merged since fork” to “Integrated since fork”;
• document the next operational gates: guarded release evidence, OnlineChefGroep-controlled npm ownership, enforceable dependency auditing, and selective upstream security/compatibility intake.

Scope

Documentation only. No runtime, package, CI, or release workflow changes.

---

^{Need help on this PR? Tag @codesmith-bot with what you need. Autofix is enabled.}

Greptile Summary

Reconciles public fork documentation with the intended prerelease state.

• Reclassifies v1.0.0-alpha.1 as prepared rather than published.
• Renames merged work as integrated work and clarifies canonical-reference wording.
• Adds operational roadmap gates for release evidence, npm ownership, dependency auditing, and selective upstream intake.

Confidence Score: 3/5

This PR should not merge until the first-release instructions are reconciled with the existing tag and the guarded workflow’s preflight behavior.

Following the documented tag-then-publish sequence for the already-tagged alpha release causes the guarded workflow to reject the real publication run; the remaining findings are documentation consistency issues.

Files Needing Attention: ROADMAP.md, CHANGELOG.md

T-Rex Logs

What T-Rex did

• Reproduced that the v1.0.0-alpha.1 tag exists and resolves to a specific commit, enabling the guarded preflight to run in dry-run mode with a notice.
• Reproduced that running the preflight with DRY_RUN=false exits with code 1 and blocks publication because the tag has pre-existing Git metadata, while the harness suppresses remote fetch, GitHub Release lookup, and npm publication during the actual preflight execution.
• Validated that the capture process for Markdown edits avoids local references and that the diff and repository-object validations for added lines exited 0.

_{Ran code and verified through T-Rex}

Important Files Changed

Filename	Overview
CHANGELOG.md	Corrects fork naming and prerelease wording, but links the new version state to stale and contradictory versioning guidance.
ROADMAP.md	Improves the fork roadmap, but documents a blocked release sequence and marks untranslated fork notices complete.

Prompt To Fix All With AI

Fix the following 3 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 3
ROADMAP.md:21
**Existing tag blocks publication**

When a maintainer follows the documented “tag, run the guarded release workflow” sequence for `v1.0.0-alpha.1`, the existing tag makes the workflow permit only a dry run, causing the real publication attempt to fail during preflight.

### Issue 2 of 3
CHANGELOG.md:8-9
**Linked version guidance is stale**

The changelog says independent versioning starts at `v1.0.0-alpha.1` and directs readers to `VERSIONING.md`, but that document still identifies `2.7.33` as current and `1.0.0` as next, leaving maintainers with conflicting release guidance.

### Issue 3 of 3
ROADMAP.md:18
**Translated fork notices remain absent**

This checked item says translated README fork notices are updated, but the Chinese, Russian, Korean, and Japanese READMEs lack the explicit fork and independent-release notice present in the English README, prematurely marking that translation work complete.

_{Reviews (1): Last reviewed commit: "docs: correct changelog release and inte..." | Re-trigger Greptile}

Greptile also left 3 inline comments on this PR.

[qodo-code-review]

ⓘ Qodo reviews are paused because your trial has ended. Ask your workspace admin to add credits to resume reviews. Manage billing

[coderabbitai]

Warning

Review limit reached

@OnlineChef, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 30 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

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 configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: a6c11d03-0486-4aa4-9e96-6380404779a3

📥 Commits

Reviewing files that changed from the base of the PR and between baadc83 and 8efc8d3.

📒 Files selected for processing (2)

• CHANGELOG.md
• ROADMAP.md

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch docs/release-state-hygiene

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[greptile-apps]

Existing tag blocks publication

When a maintainer follows the documented “tag, run the guarded release workflow” sequence for v1.0.0-alpha.1, the existing tag makes the workflow permit only a dry run, causing the real publication attempt to fail during preflight.

Artifacts

Repro: safe harness that extracts and executes the actual guarded workflow preflight

• Evidence file captured while the check ran.

Repro: exact local tag-state output for v1.0.0-alpha.1

• The full command output behind this check.

Repro: dry-run execution showing the existing-tag dry-run-only notice

• The full command output behind this check.

Repro: real-publication preflight execution rejecting the existing tag

• The full error output from the failing run.

_{Ran code and verified through T-Rex}

Prompt To Fix With AI

This is a comment left during a code review.
Path: ROADMAP.md
Line: 21

Comment:
**Existing tag blocks publication**

When a maintainer follows the documented “tag, run the guarded release workflow” sequence for `v1.0.0-alpha.1`, the existing tag makes the workflow permit only a dry run, causing the real publication attempt to fail during preflight.

How can I resolve this? If you propose a fix, please make it concise.

[greptile-apps]

Linked version guidance is stale

The changelog says independent versioning starts at v1.0.0-alpha.1 and directs readers to VERSIONING.md, but that document still identifies 2.7.33 as current and 1.0.0 as next, leaving maintainers with conflicting release guidance.

Prompt To Fix With AI

This is a comment left during a code review.
Path: CHANGELOG.md
Line: 8-9

Comment:
**Linked version guidance is stale**

The changelog says independent versioning starts at `v1.0.0-alpha.1` and directs readers to `VERSIONING.md`, but that document still identifies `2.7.33` as current and `1.0.0` as next, leaving maintainers with conflicting release guidance.

How can I resolve this? If you propose a fix, please make it concise.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!

[greptile-apps]

Translated fork notices remain absent

This checked item says translated README fork notices are updated, but the Chinese, Russian, Korean, and Japanese READMEs lack the explicit fork and independent-release notice present in the English README, prematurely marking that translation work complete.

Prompt To Fix With AI

This is a comment left during a code review.
Path: ROADMAP.md
Line: 18

Comment:
**Translated fork notices remain absent**

This checked item says translated README fork notices are updated, but the Chinese, Russian, Korean, and Japanese READMEs lack the explicit fork and independent-release notice present in the English README, prematurely marking that translation work complete.

How can I resolve this? If you propose a fix, please make it concise.