• keep the original molino-index / molino project untouched during experimentation
• let AI-assisted coding work happen in a separate private staging repository
• deploy changes to a familiar Vercel URL for inspection and review
• use the staging app as a mockup, audit surface, and public-friendly preview when appropriate
• integrate approved work back into the main project later through deliberate review

• Live staging app: https://molino-staging.vercel.app/
• Staging repository: zaruqsummers/molino-staging
• Original upstream repository: zaruqsummers/molino
• Expected deployment loop: commit to the staging repository, then Vercel auto-redeploys the staging app.

• Do not push staging experiments directly to the original upstream repository.
• Treat the original project as the source of production truth.
• Treat this clone as the feature-testing and public mockup lane.
• Make changes here first, verify them here, and only integrate back after approval.
• Keep public-facing documentation in dev-docs/ readable for non-devs.
• Keep implementation-heavy reference material in dev-docs/_PRD/ or deeper feature docs.
• Stay inside the Codex Offside Rule: update the active Plan-Commit-Build document before and after coding.

• Staging lane index
• Molino Stageup public overview
• Trips public interface
• Trips human layer checklist
• Copied production PRD reference

This clone can eventually support scheduled or triggered AI-assisted development routines, such as:

• proposed fixes
• feature drafts
• documentation projection
• branch-based experiments
• Google Sheets or Apps Script driven configuration
• generic deployment variants for different brands, businesses, or project needs

Those routines should remain human-reviewed. The core pattern is:

1. propose or generate in staging
2. deploy and inspect on Vercel
3. audit behavior, docs, and risks
4. approve or reject
5. integrate only approved work into the main project