The best community experience is not “open anything and hope.” It is knowing exactly where each kind of feedback belongs.
The README start-here section is now the fastest way to understand where to begin as a new visitor without depending on an always-open issue.
The README roadmap section now holds the near-term direction: compare-aware watch groups, health/delivery closure, and next-store priorities, so open issues can stay reserved for real active backlog.
Use Discussions / Q&A when you need help understanding the product, setup, Compare Preview flow, watch groups, or notification behavior.
Open the builder frontdoor when you want the shortest honest path for Codex, Claude Code, OpenClaw, or a similar coding-agent client.
Follow the release notes and product updates discussion if you want the public product surface to feel alive over time.
Use the dedicated Store request issue template when proposing a new merchant or store target. The remote checklist also expects the `store-request` label to stay present so the intake path does not drift from the public issue flow.
Share how you use Compare Preview or compare-aware watch groups in the public discussion thread so the product story stays grounded in real workflows.
Some public trust signals still live in GitHub settings, not in tracked source files. Some can be verified with a token-aware script, while others still require a GitHub admin to confirm them in the UI.
Keep the repository description, homepage, and topics aligned with the public product narrative. The remote checklist now prints current API-visible state instead of only repeating the intended contract.
Upload `assets/social/social-preview-1280x640.png` in the GitHub repository settings UI. The repo can verify the asset file itself, but not whether GitHub is currently using that uploaded image.
With `GITHUB_TOKEN`, the remote verifier can confirm the current code-scanning alert count. Without credentials, this stays a blind spot and still needs GitHub UI review.
Keep `main` protected and retain the current required status checks that guard the public surface: `governance`, `test`, `frontend`, `product-smoke`, `CodeQL`, and `secret-hygiene`.
The remote verifier now checks that `store-request`, `compare-preview`, `public-surface`, and `release` exist instead of assuming they are already there.
Discussions, GitHub Pages, and private vulnerability reporting should all stay enabled.
Run `python3 scripts/print_remote_repo_settings_checklist.py` for the three-layer view: expected contract, current remote facts, and manual-only checks. Add `GITHUB_TOKEN=... python3 scripts/verify_remote_github_state.py` when you want credentialed remote verification instead of contract-only review.
Keep the README start-here and roadmap sections current so public onboarding does not rely on permanently open issues.