Parent issue
Outcome
Keep the Solana, bounties, treasury, and discover app integration work explicitly staged behind the backing services it depends on.
Current state
Partial only; real backend/data workflows for the operator app remain open. Public repo truth should read hyperpush-org/hyperpush even though local workspace evidence still references mesher/frontend-exp/lib/mock-data.ts via the compatibility symlink into the sibling product repo. This issue remains active follow-through because the current operator surfaces are still partially mock-backed rather than fully shipped.
Clarified dependency boundary
This issue is downstream of the real Solana economy protocol work in:
The app/backend side should own:
- signup-triggered project provisioning
- wallet linking
- bounty workflow orchestration
- PR verification
- merged-fix payout authorization flow
- indexing / analytics / product UX
The on-chain program should not try to encode GitHub workflow logic directly; this issue is where the product/backend integration contract becomes real after the underlying Solana rails exist.
Acceptance criteria
- The integration contract for Solana, bounties, treasury, and discover is explicit.
- The issue is sequenced after the backing services exist, not treated as immediate UI wiring.
- The roadmap stays honest about what is blocked on backend/service work.
- The wording stays aligned with the current repo/code truth instead of relying on stale cross-repo or local-path assumptions.
- The issue does not treat the current mock-backed operator surfaces as already shipped.
- The app/backend integration is not considered ready until it is wired against the real localnet-proven Solana protocol path rather than mocks.
Tracker context
- Labels: enhancement, roadmap
- Project-backed: yes
Parent issue
Outcome
Keep the Solana, bounties, treasury, and discover app integration work explicitly staged behind the backing services it depends on.
Current state
Partial only; real backend/data workflows for the operator app remain open. Public repo truth should read
hyperpush-org/hyperpusheven though local workspace evidence still referencesmesher/frontend-exp/lib/mock-data.ts via the compatibility symlink into the sibling product repo. This issue remains active follow-through because the current operator surfaces are still partially mock-backed rather than fully shipped.Clarified dependency boundary
This issue is downstream of the real Solana economy protocol work in:
The app/backend side should own:
The on-chain program should not try to encode GitHub workflow logic directly; this issue is where the product/backend integration contract becomes real after the underlying Solana rails exist.
Acceptance criteria
Tracker context