Bifrost/docs/bifrost-mvp-plan.md

# Bifrost Member Alpha Plan

## Summary

- Create Bifrost as a separate GameCult app repo and deploy it on Yggdrasil.
- Build a member alpha, not a public launch.
- Use ASP.NET Core 8 with Razor Pages + HTMX and PostgreSQL.
- Support invite-only GitHub-linked members, GitHub-backed and internal work items, app-native governance, Reddit organizing threads, and internal ledgers.
- Preserve the Labor Platform loop: user/member/patron demand raises work priority and reward pressure, contributors pick up valuable work, maintainers accept completion artifacts, and Bifrost credits the contributor plus any bounty/reward allocation.
- Do not include Ethereum, wallets, DAO mechanics, or payout execution in v1.
- Align the implementation with the labor platform model in `E:\Projects\gamecult-site\GameCult\Docs\labor-platform.md`.

## System Shape

- One ASP.NET web app process for v1.
- Server-rendered UI with HTMX for progressive interactions.
- PostgreSQL as the system of record.
- Bifrost-native identity registration for login, with GitHub OAuth available as a linked external identity.
- GitHub App plus webhooks for issue and pull request lifecycle sync.
- Discord and Reddit should become native Bifrost interfaces for work, voting/priority prompts, reward discussion, maintainer notices, public organizing threads, and agent swarm routing once identity/capability claims are available.
- Yggdrasil-hosted deployment behind nginx with systemd-managed app service.

## Core Models

- `User`: authenticated app identity linked to one GitHub account
- `MemberProfile`: profile, skills, availability, links, visibility
- `Membership`: invite state, approval state, active/suspended state, roles
- `Project`: GameCult project container for tasks, motions, and ledgers
- `WorkItem`: shared model for `GitHubIssue` and `Internal` task sources
- `PrioritySignal`: user/member/patron/contributor demand or vote-like pressure attached to work
- `RewardAllocation`: bounty, credit, or reward pressure attached to a work item before completion
- `VolunteerClaim`: member intent to work on an item
- `Assignment`: approved responsibility for a work item
- `CompletionArtifact`: PR, commit, document, or other maintainer-reviewable proof of work
- `Motion`: `Management` or `Project`
- `Vote`: per-member vote tied to effective voting weight
- `LedgerEntry`: immutable patron/contributor/accounting record
- `PatronSupportEvent`: auditable support fact used to derive patron points and tier snapshots
- `PayoutProposalBatch`: admin-reviewed payout recommendation batch only
- `AuditEvent`: append-only activity and override log

## Product Rules

- Invite-only member alpha.
- Bifrost-native identity is the local account root in v1; GitHub and Heimdall-linked providers attach to that root instead of owning it.
- Authentication is separate from membership approval.
- Work items may come from GitHub issues or internal platform-native tasks.
- Voting is app-native and off-chain.
- Work priority and attached reward should be able to rise as more eligible participants want the work done.
- Contributor credit/reward is assigned only after maintainer acceptance of the completion artifact.
- Voting weight derives from patron tier plus contributor tier.
- Patron tier can be refreshed from support events through the patronage service; manual tier entry is an override path.
- Reddit comments, upvotes, flair, and thread visibility do not derive voting weight; linked patron support and contribution state do.
- Compensation is modeled internally, not executed by the platform.
- Human approval remains in the loop for governance-sensitive and payout-sensitive steps.

## Labor Platform Alignment

- Contribution points and patron points are separate systems that both matter to tiering and governance.
- Work bounties/reward pressure should be derived from transparent demand, priority, and approved allocation rules rather than private chat pressure.
- Effective balances decay over time where the labor platform rules call for decay.
- Project-specific contribution points stay distinct from global contribution points.
- Revenue share should be implemented as an internal calculation and review flow, not direct payout execution.
- Continuous care work such as maintainer, producer, and community labor must be accounted for alongside ticket-shaped work.

## Deployment Assumptions

- public hostname: `bifrost.gamecult.org`
- host: Yggdrasil
- app root target: `/srv/bifrost/app`
- env dir target: `/srv/bifrost/env`
- database: local PostgreSQL on Yggdrasil
- reverse proxy: nginx
- service supervision: systemd

## First Implementation Milestone

Build the minimum vertical slice for:

- GitHub authentication
- invite and membership gating
- project management
- work items from GitHub and internal sources
- priority signals and reward pressure for work items
- volunteering and assignment flow
- maintainer acceptance of completion artifacts
- motions and voting
- ledger entry creation
- payout proposal batch review without disbursement

## Test And Acceptance Scenarios

- invited GitHub user signs in and becomes an active member
- uninvited GitHub user cannot participate fully
- GitHub issue sync creates or updates a work item
- internal task can be created and assigned without GitHub backing
- eligible users/members/patrons/contributors can add priority pressure to work
- Reddit discussion can produce a linked Bifrost topic comment, priority signal, or motion vote without Reddit itself becoming the ledger
- work reward/credit pressure can rise from demand and be inspected before claim
- member volunteers for a task and a producer/admin assigns it
- maintainer accepts a linked PR or completion artifact before credit/reward is assigned
- completed work generates ledger entries after approval
- motion creation, voting, closure, and threshold logic work correctly
- payout proposal batch can be generated from approved ledger data without sending money
- app survives restart on Yggdrasil without data loss

## Assumptions And Defaults

- Bifrost now has an initial application slice, but it is not yet production-ready for deployment.
- v1 optimizes for legibility, auditability, and workflow proof.
- Future sessions should treat this document and `AGENTS.md` as the durable source of truth for settled decisions.
- The full staged roadmap lives in `docs/full-implementation-strategy.md`.