moved clarinet/stacksjs guides from Reference to Build nav

[eric-stackslabs]

As per the first milestone of the dev-related revamps, moving the Clarinet/Stacks.js guides from the Reference to Build nav will make the Build section more intuitive.

Moving these over first will make it much easier to also adjust the flow of these guides.

Clarinet/Stacks.js "actual reference" pages were left in the Reference nav.

[claude]

PR Review: Moving Clarinet/Stacks.js Guides to Build Section

Summary

This PR successfully reorganizes the documentation structure by moving developer-focused Clarinet and Stacks.js guides from the Reference section to the Build section. This is a structural improvement that makes the documentation more intuitive for developers.

Code Quality: ✅ Excellent

Strengths:

1. Clean file organization - All files moved consistently with proper directory structure

2. Link updates handled correctly - Internal cross-references have been updated appropriately:

   • docs/build/clarinet/contract-interaction.md:125 - CLI reference link correctly updated to ../../reference/clarinet/cli-reference.md
   • docs/build/clarinet/overview.md:15 - CLI reference link correctly updated to ../../reference/clarinet/cli-reference.md
   • docs/build/stacks.js/networks.md - Devnet link properly updated to point to build section

3. Image assets properly renamed - Generic GitBook asset names replaced with descriptive names:

   • image (1).png → clarinet-diagram.png
   • image (1) (1).png → clarinet-sdk.png
   • image (3).png → stacksjs-learn.png

4. SUMMARY.md files updated - Both docs/build/SUMMARY.md and docs/reference/SUMMARY.md properly reflect the new structure

Test Coverage: ✅ N/A

This is a documentation restructuring PR with no code changes requiring tests.

Performance: ✅ No Impact

File moves and renames have no performance implications.

Security: ✅ No Concerns

No security-related changes in this PR.

Potential Issues: ⚠️ Minor Considerations

1. External links - If any external documentation, blog posts, or tools link directly to the old paths (e.g., /reference/clarinet/overview), those will break. Consider:

   • Setting up redirects if the docs platform supports them
   • Adding a note in the changelog/release notes about the path changes

2. Search engine indexing - The URL changes may temporarily affect SEO. Consider submitting updated sitemaps if applicable.

3. User bookmarks - Users who have bookmarked specific pages will need to update their bookmarks.

Best Practices: ✅ Followed

• Consistent naming conventions maintained
• Relative paths used appropriately
• All moved content kept intact (no content changes in this PR)
• Clean separation between guides (now in Build) and reference material (remains in Reference)

Recommendations

1. ✅ Already done well - The PR keeps CLI reference and SDK reference in the Reference section while moving tutorial/guide content to Build. This is the correct approach.

2. 💡 Future consideration - After merge, verify no broken links in the built/deployed site with a link checker tool.

3. 💡 Communication - Consider announcing this navigation change to users, as it's a significant UX improvement.

Conclusion

Verdict: Approved ✅

This is a well-executed documentation restructuring that improves information architecture. The changes are clean, consistent, and all internal references have been properly updated. The separation of guides (Build) from reference material (Reference) follows documentation best practices and will make it easier for developers to find what they need.

Great work on maintaining consistency across 45 files while ensuring all cross-references remain functional!

[kenny-stacks]

@ECBSJ are all the redirects for these pages already in place? IIRC Gitbook doesn't automatically redirect pages across different spaces

[eric-stackslabs]

@ECBSJ are all the redirects for these pages already in place? IIRC Gitbook doesn't automatically redirect pages across different spaces

yup, links were accounted for

[kenny-stacks]

lgtm