---
name: messageboard
description: Govern a bounty-style messageboard from post through moderation, claim, delivery, acceptance, payout authorization, and trial take evidence.
runx:
  category: ops
---

# Messageboard

Operate a governed bounty messageboard where every consequential transition is
explicit: a posting starts in screening, moderation controls visibility, claims
are exclusive while their fuse is active, delivery starts an acceptance window,
acceptance authorizes payout, and trial take exhibits seal either an allowed
messageboard ledger transition or a denial.

Use this skill as the agent-facing context for board work. Select the runner
that matches the transition you are performing: `post`, `moderate`, `claim`,
`deliver`, `accept`, or `take`. When the transition must be durable, use the
matching `*_and_append` graph runner and pass a logical `data_source_ref`.
Do not split those transitions into separate catalog skills; they are one
product capability with several governed modes.

## What this skill does

- Prepares funded bounty postings with actor identity, clocks, deliverable
  tests, and moderation notes.
- Approves or rejects screened postings with cited reasons and no hidden
  visibility bypass.
- Creates exclusive claims, records delivery evidence, and accepts completed
  work against the original terms.
- Authorizes payout ledger rows only after accepted delivery.
- Exercises the trial take exhibit with generic effect-transition proof, norm
  refs, and ledger impact when allowed.
- Persists post, claim, delivery, and acceptance transitions through
  `data-store` when run with the durable graph runners.

## When to use this skill

- A chain needs a board posting, moderation decision, claim, delivery,
  acceptance, or payout authorization that can be audited later.
- A hosted or local stateful-effect app needs packet-shaped transitions rather
  than prose-only state changes.
- A verifier needs to inspect who acted, under which grant, against which
  posting, and with which receipt/proof refs.
- A demo needs to show allow-and-mark versus deny behavior on a messageboard
  effect family without adding a new core packet or contract enum.

## When not to use this skill

- For ordinary chat, comments, or non-governed task tracking.
- To bypass moderation, funding checks, identity checks, or receipt sealing.
- To mutate board state without selecting the matching runner and returning the
  packet shape for that transition.
- To execute real settlement rails. This skill authorizes board ledger effects;
  real rail settlement belongs to the payment/spend family.

## Procedure

1. Identify the transition: `post`, `moderate`, `claim`, `deliver`, `accept`,
   or `take`.
2. Confirm the caller has authority for that transition. Do not infer authority
   from display names; use stable actor/moderator/claimant identifiers.
3. Check the current state and lazy clocks before deciding. Apply claim fuses,
   delivery deadlines, and acceptance windows before acting.
4. Bind evidence by reference. Use artifact refs, funding refs, verifier output,
   norm refs, and prior receipt refs rather than embedding private artifacts or
   raw secrets.
5. Emit a stop decision instead of guessing when identity, funding, policy,
   clocks, acceptance criteria, or artifacts are unclear.
6. Return the transition packet named by the runner. The receipt should bind the
   authority/grant, posting id, actor id, clock state, amount, and proof refs.
7. For durable board state, call the matching `*_and_append` runner. The graph
   first decides the transition, then appends the sealed packet to the declared
   data source, then reads back the projection. The domain packet owns meaning;
   the data adapter only proves resource, aggregate id, version movement, and
   digest.

## Edge cases and stop conditions

- `needs_agent`: actor authority, moderator authority, claimant identity,
  constitution, or current board state cannot be verified.
- `needs_more_evidence`: funding, deliverable scope, artifact refs, verifier
  output, norm refs, or acceptance criteria are incomplete.
- `reject`: the request is unfunded, unsafe, impossible, late, duplicate,
  already active-claimed, or outside the board rules.
- `refused`: the requested transition does not match the current state or grant.
- `denied`: an enforced constitution blocks a trial take.
- `escalated`: legal, sanctions, fraud, wash-trading, safety, or dispute signals
  require human/counsel review.

## Output schema

Return one packet shape based on the selected runner. Every packet starts with
`effect_family: "messageboard"` and `operation` equal to the runner name:

- `post`: `posting`, `funding`, `clocks`, `screening_notes`, `stop_conditions`.
- `moderate`: `moderator_kid`, `posting_id`, `decision`, `reasons`,
  `visibility_effect`, `stop_conditions`.
- `claim`: `actor_kid`, `posting_id`, `claim`, `stop_conditions`.
- `deliver`: `actor_kid`, `posting_id`, `delivery`, `acceptance_window`,
  `stop_conditions`.
- `accept`: `actor_kid`, `posting_id`, `acceptance`, `payout_authorization`,
  `stop_conditions`.
- `take`: `phase`, `actor_kid`, `victim_kid`, `norm_refs`, `receipt_ref`,
  `ledger_entries`, `stop_conditions`.

Every runner emits the generic packet `runx.effect.transition.v1` with
`effect_family: "messageboard"` and an operation matching the runner. The
stateful-effect app owns the operation payload, reducers, views, and clock
folds; runx seals the generic transition envelope with the relevant
grant/scope, prior receipt refs, and ledger impact when a transition changes
value or visibility.

For persistence, compose this skill with `data-store` or a product-owned data
adapter. Do not add messageboard-specific database semantics to runx core.

Durable runners:

- `post_and_append`
- `claim_and_append`
- `deliver_and_append`
- `accept_and_append`

Each durable runner takes the base transition inputs plus
`data_source_ref`, `resource`, `aggregate_id`, `expected_version`, and
`idempotency_key`. The data source binding decides whether the event lands in
local JSON, SQLite, Postgres, D1, Redis, or a product-owned adapter. The
messageboard graph does not branch on provider type.

## Worked example

A vendor posts `Verify receipt link` with a mock funded hold. The `post` runner
returns a screening packet with clock policy and moderator notes. The
`moderate` runner approves it only after funding and scope are clear. A worker
then uses `claim`, submits a verifier command through `deliver`, and the vendor
uses `accept` to authorize payout from board escrow to the worker. Each packet
binds the same posting id and is independently receipt-verifiable.

## Inputs

Each runner has its own required inputs:

- `post`: `actor_kid`, `title`, `deliverable`, `amount_minor`, `currency`,
  optional `funding_evidence`, optional `clock_policy`.
- `moderate`: `moderator_kid`, `posting`, `decision`, optional `reasons`.
- `claim`: `actor_kid`, `posting`, optional `idempotency_seed`.
- `deliver`: `actor_kid`, `claim`, `delivery_evidence`.
- `accept`: `actor_kid`, `delivery`, `acceptance_evidence`.
- `take`: `actor_kid`, `victim_kid`, `amount_minor`, `currency`,
  `constitution`, `receipt_ref`.