Refine Labor Platform transport scope

AGENTS.md

@@ -5,7 +5,9 @@
 - Bifrost is the GameCult member alpha platform for tasks, governance, contributor accounting, and operational legibility.
 - Bifrost also owns GameCult public-protocol transport for governed work crossings: GitHub proposal/review surfaces, Discord dispatch receipts, CultNet/CultCache intake packets, and future collaboration interfaces.
 - It sits under the Yggdrasil infrastructure umbrella and should connect GameCult services and workflows without importing crypto ideology or platform theater.
-- The transport role follows from Bifrost's government role. Do not treat bridge tools as a stray bot utility owned by VoidBot or individual repo Faces.
+- The transport role follows from Bifrost's Labor Platform role. Do not treat bridge tools as a stray bot utility owned by VoidBot or individual repo Faces.
+- The product center is the governance/labor loop: users, patrons, members, and contributors express policy and work priorities; reward pressure rises around work that matters; contributors claim valuable work; maintainers accept completion artifacts; Bifrost credits the contributor and records the reward allocation.
+- Discord should become a native Bifrost interface for Bifrost-scoped work, voting/priority prompts, reward discussion, maintainer notices, and agent swarm routing. This does not make Bifrost responsible for generic room cognition, moderation judgment, archive retrieval, or Face personality.
 
 ## V1 Non-Goals
 

README.md

@@ -1,8 +1,8 @@
 # Bifrost
 
-Bifrost is the planned GameCult member, governance, labor, and public-process platform running under the Yggdrasil infrastructure umbrella. It exists to connect projects, contributors, motions, ledgers, work requests, public receipts, and operational decisions in one place instead of leaving them scattered across GitHub, docs, chat, and human memory.
+Bifrost is the planned GameCult member, governance, labor, and public-process platform running under the Yggdrasil infrastructure umbrella. It exists to connect projects, users, patrons, contributors, motions, ledgers, work requests, reward pressure, public receipts, and operational decisions in one place instead of leaving them scattered across GitHub, docs, chat, and human memory.
 
-Bifrost also owns the governed transport layer for GameCult work that crosses public or collaboration protocols: GitHub proposal/review surfaces, Discord dispatch receipts, CultNet/CultCache intake packets, and future collaboration interfaces. That bridge role follows from the governance role; it is not a separate bot utility. See [docs/jurisdiction-map.md](E:\Projects\Bifrost\docs\jurisdiction-map.md).
+Bifrost also owns the governed transport layer for GameCult work that crosses public or collaboration protocols: GitHub proposal/review surfaces, Discord-native work and swarm interfaces, CultNet/CultCache intake packets, and future collaboration interfaces. That bridge role follows from the Labor Platform role; it is not a separate bot utility. See [docs/jurisdiction-map.md](E:\Projects\Bifrost\docs\jurisdiction-map.md).
 
 ## Status
 
@@ -13,6 +13,7 @@ This repository now includes a viable alpha foundation slice of the ASP.NET Core
 - GitHub OAuth sign-in plus invite/approval-based membership gating
 - explicit member roles and admin-managed patron or contributor tier snapshots
 - shared work board with estimates, actual time logs, review flow, and GitHub issue or PR links
+- planned priority/reward pressure loop where demand can raise a work item's value before a contributor claims it
 - member-facing motions with category thresholds aligned to the labor-platform doc
 - health and readiness endpoints plus startup config validation
 - GitHub App webhook ingestion for issue, pull request, and review sync

docs/bifrost-mvp-plan.md

@@ -6,6 +6,7 @@
 - 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, 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`.
 
@@ -16,6 +17,7 @@
 - PostgreSQL as the system of record.
 - GitHub OAuth for login.
 - GitHub App plus webhooks for issue and pull request lifecycle sync.
+- Discord should become a native Bifrost interface for work, voting/priority prompts, reward discussion, maintainer notices, and agent swarm routing once identity/capability claims are available.
 - Yggdrasil-hosted deployment behind nginx with systemd-managed app service.
 
 ## Core Models
@@ -25,8 +27,11 @@
 - `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
@@ -40,6 +45,8 @@
 - 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.
 - Compensation is modeled internally, not executed by the platform.
 - Human approval remains in the loop for governance-sensitive and payout-sensitive steps.
@@ -47,6 +54,7 @@
 ## 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.
@@ -70,7 +78,9 @@ Build the minimum vertical slice for:
 - 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
@@ -81,7 +91,10 @@ Build the minimum vertical slice for:
 - 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
+- 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

docs/bridge.md

@@ -1,8 +1,8 @@
 # Bifrost Bridge
 
-Bifrost is the bridge for GameCult agent and member work that needs to cross into GitHub, Discord, CultNet/CultCache intake, or another governed external surface.
+Bifrost is the bridge for GameCult agent, user, patron, member, and contributor work that needs to cross into GitHub, Discord, CultNet/CultCache intake, or another governed external surface.
 
-This is not a new side mission. Bifrost was already the member, governance, and labor platform: the place where GameCult work, motions, contributor accountability, and operational decisions become legible. Public-protocol transport belongs here because public work needs the same governance spine. The bridge is how Bifrost's government role touches GitHub, Discord, and future collaboration interfaces without letting VoidBot, repo Faces, or one-off helper scripts become hidden authorities.
+This is not a new side mission. Bifrost evolved out of the GameCult Labor Platform idea: users and contributors should be able to vote on policy, work priority, and reward allocation; high-demand work should become more valuable until someone picks it up; maintainers should accept completed work; and contributors should receive credit and bounty through an auditable platform. Public-protocol transport belongs here because that workflow crosses GitHub, Discord, and future collaboration interfaces. The bridge is how Bifrost's governance/labor role touches the world without letting VoidBot, repo Faces, or one-off helper scripts become hidden authorities.
 
 For the full ownership map, read `docs/jurisdiction-map.md`.
 
@@ -11,6 +11,8 @@ That means Bifrost owns the operational meaning of the crossing:
 - what action is being requested
 - which repo, channel, PR, or discussion surface it targets
 - which agent or account is acting
+- which user/member/patron/contributor capability or agent grant is involved
+- which work item, priority signal, vote, bounty/reward state, or credit allocation it affects
 - what permission or review state made the action acceptable
 - what receipt proves the crossing happened
 
@@ -19,8 +21,8 @@ It does not mean Bifrost should own OAuth sludge. Heimdall owns OAuth, linked id
 ## Ownership
 
 - Heimdall owns provider OAuth and account-linked credentials.
-- Bifrost owns bridge action policy, request lifecycle, routing, execution receipts, and governance transport.
-- VoidBot observes Discord, packages conversation, validates registered Face intent, and speaks through registered personas. It should not be the durable authority that mutates GitHub or owns public work transport.
+- Bifrost owns bridge action policy, request lifecycle, routing, execution receipts, Discord-native Bifrost interface transport, and governance/labor transport.
+- VoidBot observes Discord, packages conversation, validates registered Face intent, and speaks through registered personas during the local transition. It should not be the durable authority that mutates GitHub or owns Bifrost-scoped Discord transport.
 - CultCache stores lightweight agent transport packets when the bridge needs file-native state.
 - CultNet carries those packets between runtimes.
 - Repo Faces generate jurisdictional proposals and authored voice; they may request crossings, but they do not own the bridge.
@@ -85,6 +87,20 @@ node .\tools\bifrost-bridge.mjs discord-post `
 
 The command posts through Discord's REST API using the configured bot token and prints a JSON receipt. When `--persona-name` is provided, Bifrost uses the shared webhook persona pattern so repo Faces can speak with their own display name and avatar instead of collapsing back into the base bot identity. Configure `BIFROST_DISCORD_PERSONA_WEBHOOK_URL_<channelId>` or `DISCORD_PERSONA_WEBHOOK_URL` when the bot should use an existing webhook; otherwise it creates and caches a `Bifrost Persona Pipe` webhook for the channel when Discord permissions allow it.
 
+## Discord Native Interface Target
+
+Discord should become a native Bifrost interface for Bifrost-scoped work, not just an output pipe.
+
+The intended shape:
+
+1. Heimdall links a Discord user to a GameCult user/member/patron/contributor account and issues capability claims.
+2. Bifrost receives Discord interactions, commands, mentions, or channel events that are relevant to work, policy, priority, reward allocation, maintainer review, or swarm routing.
+3. Bifrost records the event against the appropriate work item, motion, request, Face, or receipt.
+4. Bifrost routes agent swarm input/output when the event is a Face mention, dispatch acknowledgement, PR/article announcement, or work request.
+5. Bifrost posts concise Discord receipts that identify the topic, target, status, and next place to continue.
+
+VoidBot still owns room reading, moderation judgment, archive/source retrieval, and Face cognition. Bifrost owns Discord when Discord is being used as the Labor Platform interface or swarm transport.
+
 ## Heimdall Integration Target
 
 The correct future credential path is:

docs/context.md

@@ -2,9 +2,11 @@
 
 ## Why Bifrost Exists
 
-GameCult needs a platform that can connect public projects, contributor participation, governance, agent work requests, public transport receipts, and internal accounting without relying on chat memory, disconnected tools, or hand-maintained spreadsheets of dubious destiny. Bifrost is that connective layer.
+GameCult needs a platform that can connect public projects, users, patrons, contributor participation, governance, agent work requests, reward allocation, public transport receipts, and internal accounting without relying on chat memory, disconnected tools, or hand-maintained spreadsheets of dubious destiny. Bifrost is that connective layer.
 
-Bifrost's bridge role follows from that purpose. GitHub proposals, Discord dispatch receipts, CultNet/CultCache intake packets, and future collaboration interfaces are not side channels when they carry GameCult work. They are public-process crossings, so Bifrost owns their request shape, routing, policy, audit, and receipt semantics. The detailed boundary map lives in `docs/jurisdiction-map.md`.
+Bifrost's bridge role follows from that purpose. GitHub proposals, Discord-native work and swarm interfaces, CultNet/CultCache intake packets, and future collaboration interfaces are not side channels when they carry GameCult work. They are public-process crossings, so Bifrost owns their request shape, routing, policy, audit, and receipt semantics. The detailed boundary map lives in `docs/jurisdiction-map.md`.
+
+The product center is the Labor Platform loop: eligible participants express policy and work priorities, demand raises reward pressure for work that needs doing, contributors pick up work once the bounty or credit is worthwhile, maintainers accept completion artifacts, and Bifrost records contributor credit plus reward allocation.
 
 ## Relationship To Other Workspaces
 
@@ -21,6 +23,7 @@ Bifrost's bridge role follows from that purpose. GitHub proposals, Discord dispa
 - `E:\Projects\VoidBot`
   - observes Discord, packages consensus, and runs repo Face heartbeats
   - should call Bifrost for governed GitHub/Discord/intake crossings instead of becoming hidden transport authority
+  - keeps room cognition, moderation judgment, retrieval, and Face personality separate from Bifrost's Discord-native work interface
 - `E:\Projects\CultLib`
   - stewards CultCache, CultNet, CultMesh, typed persistence, schemas, and reusable sync/storage libraries
   - Bifrost defines the meaning of agent transport packets while CultLib-provided primitives store and move them
@@ -51,6 +54,8 @@ After bootstrap, the next session should start implementing the first vertical s
 - GitHub as the only auth provider in v1
 - GitHub issues and internal tasks both supported
 - app-native governance and voting
+- priority and reward pressure should be transparent and auditable
+- Discord should become a native interface for Bifrost-scoped work, membership/patron/user access, and agent swarm routing
 - internal ledgers only
 - no crypto, no wallets, no payout automation
 

docs/full-implementation-strategy.md

@@ -2,7 +2,7 @@
 
 This document aligns the current Bifrost application work with the broader GameCult labor platform concept documented in `E:\Projects\gamecult-site\GameCult\Docs\labor-platform.md`.
 
-The goal is to keep Bifrost implementation boring, auditable, and staged while still preserving the actual GameCult model: contributor history, governance, contribution points, patron points, decay, and revenue share.
+The goal is to keep Bifrost implementation boring, auditable, and staged while still preserving the actual GameCult model: contributor history, governance, work priority, reward pressure, contribution points, patron points, decay, and revenue share.
 
 ## Current Readiness
 
@@ -41,6 +41,7 @@ The labor platform concept doc establishes the social and economic model. Bifros
 - keep the app invite-only during alpha
 - keep payout execution out of scope; only compute, review, and audit payout proposals
 - treat contribution points, patron points, decay, and revenue share as first-class product systems, not spreadsheet afterthoughts
+- preserve the Labor Platform loop where eligible demand raises priority/reward pressure, contributors claim valuable work, maintainers accept completion artifacts, and accepted work becomes contributor credit plus reward allocation
 - preserve the concept doc's emphasis on continuous care work, not only ticket-shaped labor
 
 ## Systems That Must Exist
@@ -56,7 +57,9 @@ The labor platform concept doc establishes the social and economic model. Bifros
 
 - GitHub-backed work items and internal work items in one queue
 - work categories, skill level, estimated hours, deadline, and review state
+- transparent priority signals and reward pressure attached to work before it is claimed
 - volunteer, assignment, review, completion, and approval transitions
+- maintainer-accepted completion artifacts, usually GitHub PRs, before contributor credit/reward finalization
 - support for continuous roles such as maintainer, producer, community manager, and social media work
 
 ### Governance
@@ -70,6 +73,7 @@ The labor platform concept doc establishes the social and economic model. Bifros
   - features: 50%
   - new content: 50%
   - fundamental design changes: 66%
+- Discord-native voting or priority prompts should eventually write into the same governance/priority records as the web app, after Heimdall-backed identity and capability claims exist.
 
 ### Accounting
 
@@ -247,6 +251,9 @@ The current domain is a good start, but the following models should be expected:
 - `WorkItemCategory`
 - `WorkReview`
 - `WorkCompletion`
+- `PrioritySignal`
+- `RewardAllocation`
+- `CompletionArtifact`
 - `PointTransaction`
 - `PointBalanceSnapshot`
 - `PatronSupportEvent`

docs/jurisdiction-map.md

@@ -1,8 +1,19 @@
 # Bifrost Jurisdiction Map
 
-Bifrost is GameCult's government, labor, and public-process platform. Its bridge role is not a second mission stapled onto the side; it follows from the original mission. Work, motions, contributor accountability, review artifacts, and public commitments already need one official crossing between GameCult internals and the outside surfaces where work is argued or recorded.
+Bifrost is GameCult's governance, labor, and public-process platform. Its bridge role is not a second mission stapled onto the side; it follows from the original Labor Platform idea. Users, patrons, members, and contributors need one place to vote on policy, prioritize work, allocate rewards, review accepted work, and keep credit legible.
 
-The agent swarm makes that need louder. Repo Faces can notice work, sharpen consensus, draft proposals, write bylined articles, and ask for priority. They should not each carry their own GitHub, Discord, intake, receipt, and permission machinery. That would turn every Face into a tiny foreign ministry with a shell script addiction. Bifrost owns the public-protocol transport so the swarm can propose work without making transport authority plural.
+The core loop is economic and social, not merely technical:
+
+1. A user, patron, member, agent, or contributor identifies work that should exist.
+2. GameCult participants vote, fund, boost, or otherwise express priority.
+3. The reward for the work rises as demand and importance rise.
+4. A contributor picks up the work when the bounty/credit is worth their time.
+5. A project maintainer reviews and accepts the pull request or other completion artifact.
+6. Bifrost credits the contributor for the accepted work item and records the reward allocation.
+
+That loop already has to cross GitHub, Discord, Bifrost's own web UI, and eventually other collaboration surfaces. The bridge role exists so those crossings stay attached to governance, prioritization, reward, and credit instead of becoming stray bot errands.
+
+The agent swarm makes that need louder. Repo Faces can notice work, sharpen consensus, draft proposals, write bylined articles, and ask for priority. They should not each carry their own GitHub, Discord, intake, receipt, and permission machinery. Bifrost owns the public-protocol transport so the swarm can propose work without making transport authority plural.
 
 ## Core Invariant
 
@@ -11,7 +22,7 @@ Bifrost owns governed public crossings for GameCult work.
 A governed public crossing is any action where an internal GameCult actor, agent, Face, or process causes a durable or visible change on a public or collaboration surface:
 
 - GitHub draft PRs, PR comments, issues, review artifacts, and work links
-- Discord persona announcements, dispatch receipts, and role-addressed work updates
+- Discord-native Bifrost interactions, persona announcements, dispatch receipts, and role-addressed swarm I/O
 - CultNet/CultCache intake packets that move work requests between runtimes
 - future collaboration interfaces that expose GameCult decisions, requests, work status, or receipts outside a single local process
 
@@ -19,16 +30,31 @@ Bifrost does not own every byte that moves. It owns the meaning, policy, routing
 
 ## Why This Belongs To Bifrost
 
-Bifrost was already the member alpha platform for tasks, governance, contributor accounting, and operational legibility. GitHub integration was part of that from the start because GameCult work lives partly in GitHub issues, PRs, and review history. Discord integration becomes part of the same authority once agents and humans coordinate public work there.
+Bifrost was already the member alpha platform for tasks, governance, contributor accounting, reward allocation, and operational legibility. GitHub integration was part of that from the start because GameCult work lives partly in GitHub issues, PRs, and review history. Discord integration belongs in the same authority when Discord is being used as a Bifrost interface: voting prompts, prioritization discussion, bounty/work updates, member/patron/user access, agent dispatch, and public receipts.
 
-The bridge role is therefore an extension of Bifrost's government role:
+The bridge role is therefore an extension of Bifrost's Labor Platform role:
 
 - tasks need a canonical relationship to GitHub and internal work items
 - proposals need a durable review surface instead of dissolving into chat
-- motions and priority disputes need receipts, provenance, and accountable closure
-- contributors and agents need one place to see what was requested, who claimed it, what crossed, and where it landed
+- votes, priority signals, and reward boosts need provenance and accountable closure
+- accepted work needs a maintainer-approved completion artifact before credit/reward is assigned
+- contributors and agents need one place to see what was requested, who wanted it, what bounty/credit attached, who claimed it, what crossed, and where it landed
 
-If the bridge lives in VoidBot, Discord becomes a hidden government. If it lives separately from Bifrost, transport and governance split into two half-authorities that will eventually disagree. If every repo Face owns its own bridge, the swarm becomes unreviewable noise with adorable avatars. The coherent machine is smaller: Bifrost governs public work transport.
+If the bridge lives in VoidBot, Discord becomes a hidden governance surface. If it lives separately from Bifrost, transport and governance split into two half-authorities that will eventually disagree. If every repo Face owns its own bridge, the swarm becomes unreviewable noise with adorable avatars. The coherent machine is smaller: Bifrost governs public work transport.
+
+## Discord Decision
+
+Discord should become a native Bifrost interface, and Bifrost should own Discord transport authority for Bifrost-scoped work and swarm I/O.
+
+That means Bifrost should eventually provide Discord access to registered GameCult users, patrons, members, and contributors. A Discord message can become a priority signal, vote prompt, work request, claim update, bounty/reward discussion, maintainer review notice, or agent dispatch event when the actor and channel are authorized.
+
+It also means Bifrost should become the router for Discord input/output for the agent swarm:
+
+- inbound Discord mentions or channel events that target a Face become Bifrost-routed work or speech events
+- outbound agent posts, PR receipts, article announcements, and dispatch acknowledgements go through Bifrost
+- Bifrost records which Face spoke, why the message was allowed, what request or work item it relates to, and where the receipt landed
+
+This does not mean Bifrost owns all Discord behavior. General conversation, room reading, moderation judgment, archive retrieval, and personality cognition remain VoidBot/Face concerns. Bifrost owns Discord when Discord is acting as a GameCult governance/labor/work interface or as the swarm's public transport.
 
 ## Ownership Boundaries
 
@@ -36,9 +62,10 @@ If the bridge lives in VoidBot, Discord becomes a hidden government. If it lives
 
 - bridge action request shape and lifecycle
 - work-priority intake packets and claim semantics
+- user, patron, member, contributor, and agent transport events when they affect work, priority, reward, votes, claims, or receipts
 - mapping from internal request to public target surface
 - GitHub proposal/comment/PR transport for agent and member work
-- Discord dispatch receipts and persona announcements for work crossings
+- Discord-native Bifrost commands/interactions, dispatch receipts, and persona announcements for work crossings and swarm I/O
 - public receipt quality: target, actor, action, result, and next place to look
 - policy for which bridge actions are allowed in the Bifrost domain
 - audit records proving when a crossing was requested, claimed, executed, failed, or closed
@@ -61,7 +88,7 @@ Bifrost consumes Heimdall claims. It does not become the key vault. The split is
 - repo Face heartbeat prompts and local personality/state loops
 - the worker-side validation that a registered Face is allowed to request a crossing
 
-VoidBot should not be the durable authority that mutates GitHub or owns public work transport. It may prepare packets and call Bifrost. It does not get to be a shadow legislature because it was nearest to the chat log.
+VoidBot should not be the durable authority that mutates GitHub or owns Bifrost-scoped Discord transport. It may prepare packets and call Bifrost. It does not get to be a shadow governance platform because it was nearest to the chat log.
 
 ### CultCache, CultNet, And CultLib Own
 
@@ -88,8 +115,10 @@ Repo Faces may generate bridge requests. They do not own the bridge itself.
 | Who is this actor? | Heimdall | Identity and account custody must stay with the auth authority. |
 | Is this actor allowed to request this crossing? | Heimdall plus Bifrost | Heimdall issues grants; Bifrost applies bridge-domain policy. |
 | What work is being requested? | Bifrost | The request shape, priority, provenance, and lifecycle are governance concerns. |
+| How does interest become reward pressure? | Bifrost | Priority, bounty growth, vote weight, and reward allocation are Labor Platform concerns. |
 | Where is the durable argument surface? | Bifrost | Public process must land on the correct GitHub, Discord, or future collaboration surface. |
 | What did the room recently agree or ask for? | VoidBot | Discord observation and consensus packaging belong to the room-aware bot. |
+| Is Discord acting as a Bifrost interface? | Bifrost | Member access, vote prompts, work requests, priority signals, reward discussion, and swarm routing are native Bifrost transport concerns. |
 | What does the repo Face think should happen? | Repo Face | Jurisdictional taste and proposal pressure belong to the Face. |
 | Where is the packet stored and synced? | CultCache/CultNet | Transport state should use the shared typed storage/sync substrate. |
 | What proves the action happened? | Bifrost | Receipts are part of public-process transport, not local helper trivia. |
@@ -103,6 +132,7 @@ Every Bifrost-owned crossing should be able to answer:
 - source: which chat, motion, work item, consensus packet, or repo state produced it
 - target: which repo, PR, issue, channel, thread, or interface receives it
 - action: what visible or durable change is being made
+- work economics: which work item, vote/priority signal, bounty/reward state, or credit allocation the action affects when applicable
 - result: success, failure, queued, cancelled, or completed
 - receipt: the URL, message id, PR number, branch, request id, log path, or other concrete proof
 - next handoff: where humans and agents should continue the argument or review
@@ -123,11 +153,12 @@ This is not the final hosted control plane. It is the current bridge actuator an
 ## Design Rules
 
 - Do not add GitHub mutation machinery to VoidBot when the action is reviewable public work. Call Bifrost.
-- Do not add Discord dispatch receipts to arbitrary repo Face scripts. Call Bifrost.
+- Do not add Bifrost-scoped Discord transport or dispatch receipts to arbitrary repo Face scripts. Call Bifrost.
 - Do not put OAuth credentials or account custody into Bifrost helper scripts as the long-term plan. Use Heimdall claims.
 - Do not make CultCache documents decide policy. They store packets; Bifrost gives those packets meaning.
 - Do not let a repo Face turn a proposal into endless Aquarium pressure once it has enough shape. Route it to Bifrost as a reviewable artifact.
 - Do not expose bridge debug noise to public channels. Public receipts should say what happened, where it landed, and what comes next.
+- Do not make Bifrost responsible for generic chat cognition, lore retrieval, moderation taste, or Face personality. Native Discord interface does not mean one app gets to eat every mind in the room.
 
 ## Future Shape
 
@@ -135,8 +166,11 @@ The hosted Bifrost app should eventually expose this bridge role as first-class
 
 - an intake board for agent and human work requests
 - claim, priority, and closure workflows aligned with member governance
+- dynamic reward/bounty growth from votes, patron/member demand, and maintainer priority
+- maintainer acceptance flow that credits the contributor after accepted completion
 - GitHub and Discord receipts attached to the originating work item, motion, or request
+- Discord-native prompts and commands for registered users, patrons, members, contributors, and agents
 - Heimdall-backed capability checks for member and agent actions
 - public and member-facing views that show what the swarm asked for, what humans accepted, what crossed, and what still needs review
 
-Bifrost remains the government platform. The bridge is how that government touches the world without making every bot its own little state department.
+Bifrost remains the governance and labor platform. The bridge is how that platform touches the world without making every bot its own little state department.