legacy-redirect-canonicalization: Legacy redirect canonicalization #2

Open
std-bot wants to merge 10 commits from task/legacy-redirect-canonicalization into main
First-time contributor

Assigned idea

Benchmark authoring specification.

Summary: Add deterministic handling for legacy VitePress URL aliases in the Next.js configuration so old resource, asset, tool, extension, and useful-section paths continue to resolve permanently to their current category pages.

Task intent: Update the upstream Next.js redirect configuration to preserve search ranking for renamed legacy pages by extending and normalizing the redirect behavior already centralized in next.config.ts.

Benchmark plan: Construct a regular coding package that asks the solver to update the existing legacy redirect configuration in next.config.ts. The package should focus on concrete URL behavior: selected old paths from LEGACY_REDIRECTS must produce permanent redirects to the documented category destinations, including canonical handling for trailing-slash variants without changing the existing image remotePatterns setting.

Environment plan: The task environment should be a checkout of Wiazeph/Resource-Base at commit 9f1655c88b0c2523766f1e013d29d455d0bd9dec with the normal Node/Next.js dependencies installed. The verifier environment should run independently from the solver instructions and inspect the repository files plus, if needed, import or parse next.config.ts after installing dependencies.

Verifier plan: Create test_outputs.py to assert that next.config.ts still defines the legacy redirect map and that the exported Next config produces permanent 301 redirects for representative existing mappings such as /resources/documents -> /category/documentation, /assets/ui-design -> /category/ui-components, /tools/api -> /category/apis, and /useful-sections/ai-tools -> /category/ai-tools. It should also verify the corresponding trailing-slash source paths resolve to the same destinations and that images.remotePatterns still allows https://www.google.com/s2/**.

Oracle plan: The oracle solution should minimally edit next.config.ts by deriving redirect entries from LEGACY_REDIRECTS and adding canonical trailing-slash aliases in the redirects() output, preserving permanent redirects and existing image configuration. If tests are included in the package, the oracle may add a small local validation file, but the expected upstream change should remain centered on next.config.ts.

Difficulty plan: Current coding systems may miss that the redirect table is already a source of truth and instead hard-code duplicated redirects, accidentally alter destination slugs, omit trailing-slash behavior, or break the unrelated image configuration. The verifier should catch both incomplete coverage and overbroad rewrites.

Repo patch scope: Expected edits are limited to next.config.ts and, if the task package chooses to include repo-local validation, a narrowly scoped test file adjacent to existing configuration; no broad application or content directory changes are expected.

Anti-leakage notes: Do not expose solver-facing references to benchmark, harness, Snorkel, Harbor, std-ts, agent, stage, attempt, retry, generated task, or evaluation context. Present the work as an ordinary Next.js redirect maintenance request.

Approach: Use the existing LEGACY_REDIRECTS object as the authoritative list, generate redirect objects from it, and add normalized trailing-slash sources that point to the same destinations with permanent status. Keep the image remotePatterns block unchanged.

Verification: Run the repository’s normal lint/build command if available, then run python test_outputs.py from the package verifier. The verifier should inspect next.config.ts and confirm the concrete redirect pairs and image host pattern described above.

Risk: The main risk is that Next.js redirect matching semantics may already normalize some paths, so the task should define exact expected config output rather than relying only on runtime routing behavior. Another risk is false positives from purely textual checks, so the verifier should prefer parsing or executing the config when feasible.

Path rules: task package is tasks/; mutable upstream checkout is tasks//task/environment/repo; benchmark package files are under tasks//task; verifier/container environment belongs under tasks//task/environment; regular and UI verifier logic belongs in task/tests/test_outputs.py and test.sh only runs that file through pytest.

Agent context

Task slug: legacy-redirect-canonicalization
Branch: task/legacy-redirect-canonicalization

## Assigned idea Benchmark authoring specification. Summary: Add deterministic handling for legacy VitePress URL aliases in the Next.js configuration so old resource, asset, tool, extension, and useful-section paths continue to resolve permanently to their current category pages. Task intent: Update the upstream Next.js redirect configuration to preserve search ranking for renamed legacy pages by extending and normalizing the redirect behavior already centralized in next.config.ts. Benchmark plan: Construct a regular coding package that asks the solver to update the existing legacy redirect configuration in next.config.ts. The package should focus on concrete URL behavior: selected old paths from LEGACY_REDIRECTS must produce permanent redirects to the documented category destinations, including canonical handling for trailing-slash variants without changing the existing image remotePatterns setting. Environment plan: The task environment should be a checkout of Wiazeph/Resource-Base at commit 9f1655c88b0c2523766f1e013d29d455d0bd9dec with the normal Node/Next.js dependencies installed. The verifier environment should run independently from the solver instructions and inspect the repository files plus, if needed, import or parse next.config.ts after installing dependencies. Verifier plan: Create test_outputs.py to assert that next.config.ts still defines the legacy redirect map and that the exported Next config produces permanent 301 redirects for representative existing mappings such as /resources/documents -> /category/documentation, /assets/ui-design -> /category/ui-components, /tools/api -> /category/apis, and /useful-sections/ai-tools -> /category/ai-tools. It should also verify the corresponding trailing-slash source paths resolve to the same destinations and that images.remotePatterns still allows https://www.google.com/s2/**. Oracle plan: The oracle solution should minimally edit next.config.ts by deriving redirect entries from LEGACY_REDIRECTS and adding canonical trailing-slash aliases in the redirects() output, preserving permanent redirects and existing image configuration. If tests are included in the package, the oracle may add a small local validation file, but the expected upstream change should remain centered on next.config.ts. Difficulty plan: Current coding systems may miss that the redirect table is already a source of truth and instead hard-code duplicated redirects, accidentally alter destination slugs, omit trailing-slash behavior, or break the unrelated image configuration. The verifier should catch both incomplete coverage and overbroad rewrites. Repo patch scope: Expected edits are limited to next.config.ts and, if the task package chooses to include repo-local validation, a narrowly scoped test file adjacent to existing configuration; no broad application or content directory changes are expected. Anti-leakage notes: Do not expose solver-facing references to benchmark, harness, Snorkel, Harbor, std-ts, agent, stage, attempt, retry, generated task, or evaluation context. Present the work as an ordinary Next.js redirect maintenance request. Approach: Use the existing LEGACY_REDIRECTS object as the authoritative list, generate redirect objects from it, and add normalized trailing-slash sources that point to the same destinations with permanent status. Keep the image remotePatterns block unchanged. Verification: Run the repository’s normal lint/build command if available, then run python test_outputs.py from the package verifier. The verifier should inspect next.config.ts and confirm the concrete redirect pairs and image host pattern described above. Risk: The main risk is that Next.js redirect matching semantics may already normalize some paths, so the task should define exact expected config output rather than relying only on runtime routing behavior. Another risk is false positives from purely textual checks, so the verifier should prefer parsing or executing the config when feasible. Path rules: task package is tasks/<slug>; mutable upstream checkout is tasks/<slug>/task/environment/repo; benchmark package files are under tasks/<slug>/task; verifier/container environment belongs under tasks/<slug>/task/environment; regular and UI verifier logic belongs in task/tests/test_outputs.py and test.sh only runs that file through pytest. ## Agent context Task slug: legacy-redirect-canonicalization Branch: task/legacy-redirect-canonicalization <!-- std-ts:idea-pr-body -->
This pull request can be merged automatically.
You are not authorized to merge this pull request.
View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u origin task/legacy-redirect-canonicalization:task/legacy-redirect-canonicalization
git switch task/legacy-redirect-canonicalization

Merge

Merge the changes and update on Forgejo.

Warning: The "Autodetect manual merge" setting is not enabled for this repository, you will have to mark this pull request as manually merged afterwards.

git switch main
git merge --no-ff task/legacy-redirect-canonicalization
git switch task/legacy-redirect-canonicalization
git rebase main
git switch main
git merge --ff-only task/legacy-redirect-canonicalization
git switch task/legacy-redirect-canonicalization
git rebase main
git switch main
git merge --no-ff task/legacy-redirect-canonicalization
git switch main
git merge --squash task/legacy-redirect-canonicalization
git switch main
git merge --ff-only task/legacy-redirect-canonicalization
git switch main
git merge task/legacy-redirect-canonicalization
git push origin main
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
snorkel/root-repository-maintenance-99f07e1c783943!2
No description provided.