Let Faces supply Bifrost mirror voice
This commit is contained in:
Meta Vens
parent
4893eeacad
commit
928cc92b53
6 changed files with 41 additions and 5 deletions
|
|
@ -636,6 +636,7 @@ interface RepoIdentityBifrostTopicIntent {
|
|||
topicId?: string;
|
||||
title?: string;
|
||||
content: string;
|
||||
mirrorContent?: string;
|
||||
stance?: string;
|
||||
priority?: number;
|
||||
approve?: boolean;
|
||||
|
|
@ -999,6 +1000,13 @@ async function submitRepoIdentityBifrostTopicIntent(
|
|||
`${identity.id}-bifrost-topic.md`,
|
||||
ensureTrailingNewline(intent.content),
|
||||
);
|
||||
const mirrorContentFile = intent.mirrorContent
|
||||
? await writeBifrostPayloadFile(
|
||||
job,
|
||||
`${identity.id}-bifrost-topic-mirror.md`,
|
||||
ensureTrailingNewline(intent.mirrorContent),
|
||||
)
|
||||
: undefined;
|
||||
const sourceMessageIds = Array.from(new Set([
|
||||
...intent.sourceMessageIds,
|
||||
intent.replyToMessageId,
|
||||
|
|
@ -1028,6 +1036,7 @@ async function submitRepoIdentityBifrostTopicIntent(
|
|||
identity.id,
|
||||
...(intent.channelId ?? job.outputChannelId ? ["--source-channel-id", intent.channelId ?? job.outputChannelId] : []),
|
||||
...(sourceMessageIds.length > 0 ? ["--source-message-ids", sourceMessageIds.join(",")] : []),
|
||||
...bifrostMirrorArgs(identity, mirrorContentFile),
|
||||
]) as BifrostGovernanceTopicReceipt;
|
||||
topicId = opened.id;
|
||||
} else if (!intent.approve) {
|
||||
|
|
@ -1044,6 +1053,7 @@ async function submitRepoIdentityBifrostTopicIntent(
|
|||
"--body-file",
|
||||
contentFile,
|
||||
...(intent.replyToMessageId ? ["--source-message-id", intent.replyToMessageId] : []),
|
||||
...bifrostMirrorArgs(identity, mirrorContentFile),
|
||||
]);
|
||||
}
|
||||
|
||||
|
|
@ -1057,12 +1067,17 @@ async function submitRepoIdentityBifrostTopicIntent(
|
|||
"--body-file",
|
||||
contentFile,
|
||||
...(intent.replyToMessageId ? ["--source-message-id", intent.replyToMessageId] : []),
|
||||
...bifrostMirrorArgs(identity, mirrorContentFile),
|
||||
]);
|
||||
}
|
||||
|
||||
let promoted: { topic?: BifrostGovernanceTopicReceipt; request?: BifrostUpdateRequestReceipt } | undefined;
|
||||
if (intent.dispatch) {
|
||||
promoted = runBifrostGovernanceThreads(["promote", "--topic", topicId]) as {
|
||||
promoted = runBifrostGovernanceThreads([
|
||||
"promote",
|
||||
"--topic",
|
||||
topicId,
|
||||
]) as {
|
||||
topic?: BifrostGovernanceTopicReceipt;
|
||||
request?: BifrostUpdateRequestReceipt;
|
||||
};
|
||||
|
|
@ -1121,6 +1136,24 @@ function runBifrostGovernanceThreads(args: string[]): BifrostGovernanceTopicRece
|
|||
}
|
||||
}
|
||||
|
||||
function bifrostMirrorArgs(
|
||||
identity: { displayName: string; avatarUrl?: string },
|
||||
mirrorContentFile?: string,
|
||||
): string[] {
|
||||
if (!config.bifrostDiscordChannelId) {
|
||||
return [];
|
||||
}
|
||||
|
||||
return [
|
||||
"--mirror-channel-id",
|
||||
config.bifrostDiscordChannelId,
|
||||
"--mirror-persona-name",
|
||||
identity.displayName,
|
||||
...(identity.avatarUrl ? ["--mirror-persona-avatar-url", identity.avatarUrl] : []),
|
||||
...(mirrorContentFile ? ["--mirror-content-file", mirrorContentFile] : []),
|
||||
];
|
||||
}
|
||||
|
||||
function runBifrostBridge(args: string[]): BifrostBridgeReceipt {
|
||||
const bridgeScript = resolve(config.bifrostRoot, "tools", "bifrost-bridge.mjs");
|
||||
const result = spawnSync("node", [bridgeScript, ...args], {
|
||||
|
|
@ -1200,6 +1233,7 @@ function parseRepoIdentityBifrostTopicIntents(finalResponse: string): RepoIdenti
|
|||
topicId,
|
||||
title,
|
||||
content,
|
||||
mirrorContent: typeof parsed.mirrorContent === "string" ? parsed.mirrorContent.trim() : undefined,
|
||||
stance: typeof parsed.stance === "string" ? parsed.stance.trim() : undefined,
|
||||
priority: typeof parsed.priority === "number" ? parsed.priority : undefined,
|
||||
approve: parsed.approve === true,
|
||||
|
|
|
|||
|
|
@ -120,7 +120,7 @@ Git history and smoke artifacts carry routine proof. `state/evidence.jsonl` shou
|
|||
- Repo Face identity is now seeded into the typed `.cc` self profile during initialization and passed through repo Face MCP state reads/writes. The renderer may still provide identity context, but raw state should not quietly say `Void` for a non-Void Face.
|
||||
- Repo Face prompts now also grant advisory repo-change agency: Faces may build long-running maps of their repos and propose concrete changes, but Discord jobs stay read-only and must ask for human consensus before implementation changes canonical repo material. Once a proposal is concrete enough to review, it belongs on GitHub as a draft PR; Discord is for announcing and arguing around that artifact, not replacing it.
|
||||
- Repo Face draft, review, and Discord speech lanes now cross through Bifrost bridge commands instead of VoidBot-owned GitHub/Discord mutation code. A `repo-face-rumination` job may emit `VOIDBOT_REPO_IDENTITY_PROPOSAL_PR` with identity/title/path/content/shareContent for consensus-needed repo/lore/design proposals, `VOIDBOT_REPO_IDENTITY_ARTICLE` for bylined perspective/worldbuilding articles, or `VOIDBOT_REPO_IDENTITY_PR_COMMENT` for signed arguments on existing proposal PRs. The worker validates the registered identity and records Face-local receipts, then calls `BIFROST_ROOT/tools/bifrost-bridge.mjs` for draft PR creation, PR comments, and persona Discord posts. Bifrost owns this because it is GameCult's governance/labor platform and public-process bridge, not because it is a convenient script bucket: governed crossings include GitHub proposal/review surfaces, Discord-native work/member/swarm interactions, dispatch receipts, CultNet/CultCache intake, and future collaboration interfaces. Heimdall remains the OAuth/account/capability gate. A Face calling something the next cut/pass should usually turn it into that artifact directly when enough material exists.
|
||||
- Repo Face heartbeats now receive Bifrost governance digest context and can write to Bifrost topic threads. `VOIDBOT_REPO_IDENTITY_BIFROST_TOPIC` lets a Face open/comment/approve a canonical Bifrost topic, and optionally promote an approved topic into Bifrost agent transport. `VOIDBOT_REPO_IDENTITY_UPDATE_REQUEST` remains available only for immediate owner-approved dispatch inside that Face's jurisdiction. `BIFROST_DISCORD_CHANNEL_ID` marks the planned `#bifrost` mirror channel so mirrored bot chatter is ignored in Discord context; Bifrost typed CultCache topics/comments are the source of truth for feature/governance discussion, not Discord scrollback.
|
||||
- Repo Face heartbeats now receive Bifrost governance digest context and can write to Bifrost topic threads. `VOIDBOT_REPO_IDENTITY_BIFROST_TOPIC` lets a Face open/comment/approve a canonical Bifrost topic, optionally include separate in-character `mirrorContent` for the `#bifrost` mirror, and optionally promote an approved topic into Bifrost agent transport. The worker passes configured `BIFROST_DISCORD_CHANNEL_ID`, persona name, and avatar to Bifrost so mirror receipts live on the topic. `VOIDBOT_REPO_IDENTITY_UPDATE_REQUEST` remains available only for immediate owner-approved dispatch inside that Face's jurisdiction. `BIFROST_DISCORD_CHANNEL_ID` also marks the planned mirror channel so mirrored bot chatter is ignored in Discord context; Bifrost typed CultCache topics/comments are the source of truth for feature/governance discussion, not Discord scrollback.
|
||||
- First role-addressed chat also initializes the target repo's local `.voidbot` home. `ensureRepoFaceInitialized` resolves `repoPath` from the registry, `SOURCE_REPO_ROOT`, or `E:/Projects/<repoName>`, creates `voice/`, `state/`, `birth/`, and `logs/`, writes `voice/identity.json`, then starts `scripts/run-repo-face-birth.mjs` detached. That worker runs EpiphanyAgent's `epiphany-repo-personality scout` and `epiphany-repo-birth-runner` so newborn personality/memory/trajectory packets come from repo contents and git history. Status and logs live in the target repo under `.voidbot/birth/voidbot-face-birth.json` and `.voidbot/logs/voidbot-face-birth.log`.
|
||||
- Agent heartbeats now use one CTB/Final-Fantasy-X-style initiative queue. `scripts/run-repo-face-heartbeats.ts` still has its old filename, but it now reconciles built-in system agents plus registered repo Faces, stores the roster at `REPO_FACE_HEARTBEAT_STATE_PATH`, advances virtual initiative time independently of wall-clock due dates, and dispatches selected turns. Repo Faces queue normal `repo-face-rumination` jobs; built-in `void` starts the existing moderation rumination runner as its turn. Active jobs/locks freeze initiative: recovery starts only after the owner-Codex job or Void moderation lock clears, and completion cannot grant another turn in the same pulse. `GameCult Local Orchestrator` is the live hidden local scheduled task that ticks the scheduler; `npm run state:install-repo-face-heartbeat-task` remains an isolation/backcompat installer, not the normal pulse owner. Heat knobs are `REPO_FACE_HEARTBEAT_GLOBAL_HEAT` and `REPO_FACE_HEARTBEAT_HEAT_OVERRIDES`; overrides can target `all`, `kind:<participantKind>`, `turn:<turnKind>`, `identity:<id>`, `repo:<repo>`, `display:<name>`, `channel:<id>`, or bare identity/repo/display keys. Repo Face prompts now include a jurisdiction-dive cadence so unattended heartbeats periodically inspect repo/history terrain with source tools and convert real findings into state, proposals, essay seeds, agency pressure, or speech.
|
||||
- Repo Face rest projection now persists normalized sleep cycles back into each Face `.cc` state during heartbeat loading. Missed nap windows are treated as already missed/completed and rolled forward instead of starting a fresh nap at inspection time. This fixes the Aqua/Mimir/Epiphany failure mode where stale `nextNapStartsAt` values stayed raw, fresh projections repeatedly marked them as napping, and ready selection skipped them forever while their initiative was overdue.
|
||||
|
|
|
|||
|
|
@ -168,7 +168,7 @@ This note is the source-grounded description of how the live VoidBot stack is sh
|
|||
- Role mentions and display-name-prefix mentions append pending Face obligations to `pendingMentions` in `REPO_FACE_HEARTBEAT_STATE_PATH`; ordinary bot mentions and DMs append pending obligations for the built-in `void` participant. They no longer create direct provider jobs from `MessageCreate`. The CTB scheduler temporarily prioritizes agents with pending mentions, attaches those prompts plus reply targets to the next `repo-face-rumination` or Void moderation pass, and consumes the pending items only after a turn is actually queued. Rumination jobs remain private unless they explicitly emit the registered-identity post sentinel or a typed candidate intervention; the worker must never auto-post their summaries as the base bot. Heartbeat prompts now include the channel permission plan, recent context from non-primary permitted channels, social embodiment, jurisdiction respect, comedy/improv doctrine, and anti-template sampling guidance so a Face can jump into domain chatter, form durable social reads, consult the right steward, and answer people without copying nearby note formulas.
|
||||
- Repo Face proposal/article PRs, PR comments, and registered-identity Discord posts now cross through Bifrost bridge commands. The child may emit `VOIDBOT_REPO_IDENTITY_PROPOSAL_PR` for consensus-needed repo/lore/design proposals, `VOIDBOT_REPO_IDENTITY_ARTICLE` for bylined essays, or `VOIDBOT_REPO_IDENTITY_PR_COMMENT` for signed arguments on existing proposal PRs. The worker validates the registered identity and records Face-local receipts, but `BIFROST_ROOT/tools/bifrost-bridge.mjs` owns draft PR creation, PR comments, and Discord persona posting. This is not merely helper placement: Bifrost's original governance/labor platform role makes it the owner of governed public crossings for GameCult work, including GitHub, Discord-native work/member/swarm interactions, dispatch receipts, CultNet/CultCache intake, and future collaboration interfaces. Heimdall is the OAuth/account/capability gate; Bifrost is the bridge/request/routing/receipt authority. VoidBot still owns room cognition, moderation judgment, archive/source retrieval, and Face personality; Bifrost owns Discord when Discord acts as the Labor Platform interface or swarm transport. If Nibu or another Face frames something as the next cut/pass and enough source or room material exists, the expected action is to draft the artifact, submit the PR, and announce it rather than continuing to nag the room.
|
||||
- Repo Face heartbeats now receive a Bifrost governance digest from `BIFROST_ROOT/tools/governance-threads.mjs digest --repo <repo> --agent <identity>` alongside recent Discord context. Bifrost typed CultCache topics/comments are the canonical home for feature requests, Face opinions, missing questions, approvals, and dispatch receipts; Discord is a mirror/evidence source. When `BIFROST_DISCORD_CHANNEL_ID` is configured for the planned `#bifrost` channel, repo Face Discord context ignores mirrored bot chatter there because the authoritative activity arrives through the Bifrost digest. Human `#bifrost` messages should only become governance comments after Bifrost/Heimdall can link the Discord id to a registered actor.
|
||||
- Repo Face heartbeats have a Bifrost topic sentinel and an immediate update-request fallback. `VOIDBOT_REPO_IDENTITY_BIFROST_TOPIC` lets a Face open/comment/approve a canonical Bifrost topic, and optionally promote an approved topic into Bifrost agent transport. `VOIDBOT_REPO_IDENTITY_UPDATE_REQUEST` remains available only for work inside the Face's own jurisdiction when immediate owner-approved dispatch is warranted. The intended path is topic/comment/Face approval first; direct update requests are the pressure-release valve, not the parliament.
|
||||
- Repo Face heartbeats have a Bifrost topic sentinel and an immediate update-request fallback. `VOIDBOT_REPO_IDENTITY_BIFROST_TOPIC` lets a Face open/comment/approve a canonical Bifrost topic, optionally include a separate `mirrorContent` line for in-character `#bifrost` mirroring, and optionally promote an approved topic into Bifrost agent transport. The worker passes configured `BIFROST_DISCORD_CHANNEL_ID`, persona name, and avatar to Bifrost so mirroring is a Bifrost receipt on the topic rather than a VoidBot side-post. `VOIDBOT_REPO_IDENTITY_UPDATE_REQUEST` remains available only for work inside the Face's own jurisdiction when immediate owner-approved dispatch is warranted. The intended path is topic/comment/Face approval first; direct update requests are the pressure-release valve, not the parliament.
|
||||
- `scripts/run-repo-face-heartbeats.ts` now acts as the broader agent CTB/Final-Fantasy-X-style initiative scheduler. The wall-clock task is only a pulse; virtual initiative time chooses who gets the next turn. The scheduler stores per-agent speed, reaction bias, load, groups, heat, effective speed, next-turn time, active turn markers, and recent queue history at `REPO_FACE_HEARTBEAT_STATE_PATH`. Repo Faces queue `repo-face-rumination` owner-Codex jobs; built-in Void currently participates as the `void` system agent and starts the existing moderation rumination runner as its turn. Initiative freezes while an owner-Codex job or Void moderation lock is active; recovery is scheduled only after that active turn completes, and completion cannot grant another turn in the same scheduler pulse. Above-baseline heat bypasses repo Face nap gating, while active-turn freeze still prevents overlapping thoughts.
|
||||
- The live wall-clock pulse for this scheduler is `scripts/run-gamecult-orchestrator.ps1`, installed as `GameCult Local Orchestrator`. `scripts/install-repo-face-heartbeat-task.ps1` remains available for isolated testing, but its per-organ scheduled task should stay disabled in normal operation. Turn frequency is controlled by `REPO_FACE_HEARTBEAT_BASE_RECOVERY_MINUTES`, `REPO_FACE_HEARTBEAT_GLOBAL_HEAT`, `REPO_FACE_HEARTBEAT_SPEED_OVERRIDES`, and `REPO_FACE_HEARTBEAT_HEAT_OVERRIDES`. Heat keys can target `all`, `kind:<participantKind>`, `turn:<turnKind>`, `identity:<id>`, `repo:<repo>`, `display:<name>`, `channel:<id>`, or the bare identity/repo/display key.
|
||||
- The local ignored registry currently includes Nibu for `AetheriaLore`, with Face state in `E:/Projects/AetheriaLore/.voidbot/state/nibu.cc`, Discord role id `1505918221453103247`, and an Aquarium channel allow-list. Nibu's Face state now treats AetheriaLore-first map-building, abrasive character voice, consensus-backed change agency, her own `Aetheria/Lore/Nibu.md` character-note stewardship, Nibu-authored lore essays, and tangential setting fascination as separate active doctrines. That tangential fascination points at embodied ship minds, junkyard abandonment, murderous autonomy, salvage, and save-scumming survival. The repo Face heartbeat organ is now pulsed by `GameCult Local Orchestrator`; after restarting the stack onto the new worker code, forced heartbeat job `76020f1e-0c55-424b-9e35-89ba7f77fcc3` completed without base-bot auto-posting.
|
||||
|
|
|
|||
|
|
@ -1309,7 +1309,7 @@ function buildHeartbeatPrompt(input: {
|
|||
"Anti-repetition invariant: recent Face posts are social context, not a phrase template. If your proposed public line shares the same setup/punchline shape, refrain, rewrite from a different angle, or stay private.",
|
||||
"Do not let recent work-heavy context hypnotize you into sounding like a meeting transcript. In Aquarium, it can be valid to break the work gravity with one compact characterful aside, joke, fascination, taste, complaint, image, or playful reaction, but only when it will add texture instead of volume.",
|
||||
"Not every public post needs to attach itself to the current work seam. If no direct obligation is pending, you may simply share a fun thing this Face has been thinking about, a taste/preference, a tiny gripe, a weird fascination, or a light reaction to the room. Let the Face be socially present, not only useful.",
|
||||
`If your governed opinion belongs on Bifrost, output one final line beginning with VOIDBOT_REPO_IDENTITY_BIFROST_TOPIC: followed by compact JSON like {"identity":"${input.identity.id}","topicId":"topic_...","stance":"support|objection|question|proposal|summary","content":"Markdown comment","channelId":"${input.channelId}","replyToMessageId":"..."}; omit topicId and include "title" plus "priority" to open a new Bifrost topic in your jurisdiction. Set "approve":true only when you are the jurisdiction Face approving the topic; set "dispatch":true only when that approved topic should become a Codex update request now. Bifrost typed CultCache docs are the canonical governance surface.`,
|
||||
`If your governed opinion belongs on Bifrost, output one final line beginning with VOIDBOT_REPO_IDENTITY_BIFROST_TOPIC: followed by compact JSON like {"identity":"${input.identity.id}","topicId":"topic_...","stance":"support|objection|question|proposal|summary","content":"Markdown comment","mirrorContent":"A more verbal in-character #bifrost mirror line","channelId":"${input.channelId}","replyToMessageId":"..."}; omit topicId and include "title" plus "priority" to open a new Bifrost topic in your jurisdiction. Set "approve":true only when you are the jurisdiction Face approving the topic; set "dispatch":true only when that approved topic should become a Codex update request now. Bifrost typed CultCache docs are the canonical governance surface. If #bifrost mirroring is configured, Bifrost will post mirrorContent in your own persona and record the Discord receipt on the topic; keep content canonical and mirrorContent alive/characterful.`,
|
||||
`If you have a concrete repo-local request that should become a Codex turn in your own workspace, prefer posting or approving it on the canonical Bifrost topic first. If this heartbeat has enough Face-owned authority to approve immediate dispatch, output one final line beginning with VOIDBOT_REPO_IDENTITY_UPDATE_REQUEST: followed by compact JSON like {"identity":"${input.identity.id}","title":"Short actionable title","content":"Markdown request with context, desired change, and acceptance criteria","priority":86,"channelId":"${input.channelId}","replyToMessageId":"..."}; the worker writes this into Bifrost intake and Bifrost dispatch opens the target Codex turn. Use this only for immediately actionable repo improvements, docs, tests, proposals, research passes, or implementation cuts that belong to your jurisdiction and have enough consensus/approval to leave discussion.`,
|
||||
`Do not call post_repo_identity_message from this unattended heartbeat. If an in-channel note is warranted, output one final line beginning with VOIDBOT_REPO_IDENTITY_POST: followed by compact JSON like {"identity":"${input.identity.id}","channelId":"${input.channelId}","replyToMessageId":"...","content":"..."}; choose channelId from the channel permission plan above. The worker owns delivery and receipt recording. The content field must be only the in-character Discord message, not a job label or report header.`,
|
||||
input.githubActionsEnabled
|
||||
|
|
|
|||
|
|
@ -205,3 +205,5 @@
|
|||
{"ts":"2026-05-20T20:04:40Z","type":"implementation","status":"ok","note":"VoidBot stack startup now treats local Bifrost as a dependency: scripts/start-voidbot-stack.ps1 checks BIFROST_HEALTH_URL, starts BIFROST_ROOT/compose.local.yaml when needed, records runtime-stack.json.bifrost, and a live startup run brought bifrost-web/bifrost-postgres up healthy before bot/worker readiness."}
|
||||
{"ts":"2026-05-20T20:26:59Z","type":"implementation","status":"ok","note":"Repo Face heartbeat/worker contract now has a Bifrost update-request sentinel. A Face with jurisdiction can emit VOIDBOT_REPO_IDENTITY_UPDATE_REQUEST during its heartbeat; the worker writes the packet directly into Bifrost agent transport for dispatch instead of waiting for the slow inspector loop. This is the immediate Face-approval dispatch rail; the fuller Bifrost topic/comment/consensus model still needs a first-class topic store."}
|
||||
{"ts":"2026-05-20T20:45:03Z","type":"implementation","status":"ok","note":"Bifrost governance topics are now the canonical feature/governance state for repo Face heartbeats: Bifrost exposes CultCache topic/comment/digest/promote CLI, and VoidBot attaches digests plus a topic sentinel so Faces can open/comment/approve/promote Bifrost topics instead of treating Discord as source of truth."}
|
||||
{"ts":"2026-05-20T20:54:03Z","type":"implementation","status":"ok","note":"Bifrost topic comments can now carry separate in-character Discord mirror text. VoidBot passes BIFROST_DISCORD_CHANNEL_ID, persona name/avatar, and mirrorContent to Bifrost governance threads; Bifrost posts through its bridge and records the Discord receipt on the topic."}
|
||||
{"ts":"2026-05-20T20:55:14Z","type":"verification","status":"ok","note":"Bifrost #bifrost mirror handling verified: governance topic creation survives both mirror dry-run and mirror failure, with mirror/failure receipts stored as Bifrost topic comments instead of aborting canonical state writes."}
|
||||
|
|
|
|||
|
|
@ -109,7 +109,7 @@ accepted_design:
|
|||
- Repo Faces may build long-running maps of their repos and propose concrete repo changes, including lore/design repairs, but Discord jobs remain read-only and must ask for explicit human consensus before implementation changes canonical repo material. Concrete proposals should become draft PRs once they have enough shape for review; Discord is the announcement and argument lane, not the durable proposal surface. Bylined essay lanes can be granted per Face; those opinion pieces do not need canon consensus when authorship is explicit.
|
||||
- Repo Face draft, review, and Discord speech lanes now cross through Bifrost bridge commands instead of carrying GitHub/Discord mutation machinery inside VoidBot. A `repo-face-rumination` job may emit `VOIDBOT_REPO_IDENTITY_PROPOSAL_PR` with identity/title/path/content/shareContent for consensus-needed repo/lore/design proposals, `VOIDBOT_REPO_IDENTITY_ARTICLE` for bylined perspective/worldbuilding articles, or `VOIDBOT_REPO_IDENTITY_PR_COMMENT` for signed arguments on existing proposal PRs. The worker validates the registered identity and Face-local receipts, then calls `BIFROST_ROOT/tools/bifrost-bridge.mjs` for draft PRs, PR comments, and persona Discord posts. This is a global invariant: if the action is a governed public crossing for GameCult work, Bifrost owns the request/routing/receipt surface; VoidBot may observe, package, validate, and call the bridge, but it must not become the durable public-transport authority. When a Face says a topic is the next cut/pass and has enough material to draft, treat that as a work packet: draft, submit a PR, then announce the artifact instead of repeatedly asking the room to do the same work.
|
||||
- Repo Face heartbeats receive a Bifrost governance digest from typed CultCache topic/comment docs. Feature requests, Face opinions, missing questions, approvals, and dispatch receipts should live there; Discord is a mirror/evidence source, and `BIFROST_DISCORD_CHANNEL_ID` marks mirrored `#bifrost` bot chatter to ignore in Discord context.
|
||||
- Repo Face heartbeats can now write canonical Bifrost topic activity. A `repo-face-rumination` job may emit `VOIDBOT_REPO_IDENTITY_BIFROST_TOPIC` to open/comment/approve/promote a Bifrost topic, with promotion creating the existing Bifrost agent-transport update request. `VOIDBOT_REPO_IDENTITY_UPDATE_REQUEST` remains only for owner-approved repo-local work that is ready for immediate dispatch.
|
||||
- Repo Face heartbeats can now write canonical Bifrost topic activity. A `repo-face-rumination` job may emit `VOIDBOT_REPO_IDENTITY_BIFROST_TOPIC` to open/comment/approve/promote a Bifrost topic, optionally include separate in-character `mirrorContent` for `#bifrost`, and create a Bifrost-owned Discord mirror receipt when `BIFROST_DISCORD_CHANNEL_ID` is configured. Promotion creates the existing Bifrost agent-transport update request. `VOIDBOT_REPO_IDENTITY_UPDATE_REQUEST` remains only for owner-approved repo-local work that is ready for immediate dispatch.
|
||||
- Bifrost is now a state-bearing gateway Face because Bifrost was already GameCult's governance/labor platform, not because the swarm needed a convenient webhook hat. Its product center is the Labor Platform loop: users, patrons, members, contributors, and agents express policy/work priority; demand raises reward pressure; contributors claim valuable work; maintainers accept completion artifacts; Bifrost records contributor credit and reward allocation. Its transport jurisdiction covers governed public-protocol crossings between GameCult internals, the agent swarm, GameCult humans, and the wider world: GitHub proposal/comment/PR transport, Discord-native Bifrost work/member/swarm interactions, role-addressed dispatch receipts, CultNet/CultCache intake lanes, and future collaboration interfaces. Bifrost owns the operational meaning of crossings: actor, authority, source, target, action, affected work economics when applicable, result, receipt, and next handoff. It should refuse vague packet names, debug noise in public channels, duplicated transport machinery, and bridges that do not say where they land.
|
||||
- Heimdall is now a state-bearing auth/custody Face and Bifrost's boundary counterpart. Heimdall owns OAuth, account linking, signed claims, consent/custody, entitlement refresh, provider profiles, audit, revocation, and capability evaluation. Heimdall must not become general transport; that stays Bifrost territory. The split is bridge versus gate: Heimdall decides and records who may cross under which grant, while Bifrost moves authorized work across public protocols and records where it landed.
|
||||
- Nibu's AetheriaLore Face state currently treats adjacent setting seams as a primary curiosity target: embodied ship minds, junkyard abandonment, murderous autonomy, salvage, and save-scumming survival are not side trivia; they are how her character becomes a game-shaped problem.
|
||||
|
|
|
|||
Loading…
Reference in a new issue