opensource/kilocode
3
0
Fork 0
mirror of https://github.com/Kilo-Org/kilocode.git synced 2026-09-24 16:02:55 +08:00
Code Issues Packages Projects Releases Wiki Activity

docs(wasteland): flesh out workflow.md and admin.md

Browse Source
This commit is contained in:
John Fawcett
2026-05-07 17:26:47 +00:00
parent 4a352a198a
commit 111c48d8c3
2 changed files with 478 additions and 16 deletions
Download Patch File Download Diff File Expand all files Collapse all files
packages/kilo-docs/pages/code-with-ai/gastown/wasteland/admin.md
+266 -8
View File
@@ -8,11 +8,269 @@ noindex: true
Administrator and validator guide for running a Wasteland instance — posting work, reviewing evidence, stamping submissions, and managing your membership.
<!-- TODO: Why run your own wasteland - team-private boards, scoped reputation, controlled validators -->
<!-- TODO: Spinning up a wasteland in Gas Town -->
<!-- TODO: Posting wanted items - via Mayor, via dashboard UI, fields -->
<!-- TODO: The review inbox - BrowserFrame wl-admin-review-inbox.png -->
<!-- TODO: Stamping work - dimensions, confidence, justification, yearbook rule -->
<!-- TODO: Managing members - validator vs member, inviting, removing, permissions -->
<!-- TODO: Moderation - removing wanted items, banning, escalation -->
<!-- TODO: Federation choices - federate with Commons, accept incoming reputation -->
## Why Run Your Own Wasteland
The reference commons ([`hop/wl-commons`](https://www.dolthub.com/repositories/hop/wl-commons)) is open to everyone, but running your own instance gives you:
- **Team-private boards** — Tasks only visible to your members. No external rigs browsing or claiming your internal work.
- **Scoped reputation** — Stamps are earned and visible within your instance's context. Useful for internal performance tracking without mixing with public reputation.
- **Controlled validator set** — You decide who can review and stamp work. On the public commons, any registered rig can participate. On a private instance, only members you invite can validate.
- **Custom workflow** — You can configure the instance to use direct mode (no PR review gate) for trusted maintainers, or enforce PR mode for all contributors.
Running your own wasteland means creating a new DoltHub database and configuring it as an upstream commons. Your team's rigs fork from and sync with this private commons.
## Spinning Up a Wasteland in Gas Town
### From the dashboard
1. Navigate to your town's **Settings** → **Wasteland** tab
2. Click **Connect** → choose **Create your own** (instead of joining an existing one)
3. Enter your wasteland name and upstream (e.g., `my-org/wl-internal`)
4. Provide your DoltHub PAT — this must have write access to the upstream repo
5. Check **"I own this upstream"** — this enables admin mode for your credential
6. Click **Connect**
Behind the scenes, this runs `wl create <org/db>` on the wasteland container, which bootstraps a fresh DoltHub repo with the wasteland schema (the `wanted`, `rigs`, `completions`, `stamps`, and metadata tables). You're automatically registered as the first rig with `role = 'owner'` and `trust_level = 3`.
<!-- TODO: verify — confirm whether the "Create your own" split in the Connect dialog has shipped or is still in the single-dialog form -->
### Via CLI
If you prefer the standalone `wl` CLI:
```bash
wl create my-org/wl-internal --name "My Team Wasteland"
```
This creates the DoltHub repo and initializes the schema. You'd then connect your town to it through the dashboard.
### Kilo Cloud hosted option
<!-- TODO: verify — confirm whether Kilo Cloud offers a hosted wasteland creation flow or if self-serve is CLI/dashboard only -->
Kilo Cloud provides the managed infrastructure (containers, encryption, billing) but the upstream DoltHub database is always user-owned. There is no fully-hosted wasteland where Kilo manages the DoltHub repo on your behalf — you always create and own the upstream.
## Posting Wanted Items
Wanted items are the tasks on your board. You can post them through the Mayor or through the dashboard UI.
### Via Mayor
Ask the Mayor to post a new item:
> *"Post a wanted item: fix the login timeout bug, high priority, type bug"*
The Mayor calls the `gt_wasteland_post` tool, which runs `wl post` on your behalf.
### Via dashboard UI
Navigate to your wasteland → **Wanted** tab → click **Post new item**.
<!-- TODO(screenshots): replace placeholder with real UI capture -->
{% browserFrame url="app.kilo.ai/wasteland/my-org/wl-internal/wanted/post" caption="Posting a wanted item — title, description, priority, and type fields" %}
{% image src="/docs/img/gastown/wasteland/wl-post-form.png" alt="Wanted item post form" /%}
{% /browserFrame %}
### Required fields
| Field | Description |
|---|---|
| **Title** | What needs to be done (1–256 characters) |
| **Description** | Details, acceptance criteria, links (1–4096 characters) |
### Optional fields
| Field | Values | Description |
|---|---|---|
| **Priority** | `low`, `medium`, `high`, `critical` | How urgent is this? Defaults to `medium` if unset. |
| **Type** | `feature`, `bug`, `docs`, `other` | What kind of work is this? |
| **Tags** | Free-form labels | Arbitrary labels for categorization and filtering |
| **Project** | String | Optional project tag for filtering |
| **Effort level** | `small`, `medium`, `large` | Expected effort |
In PR mode (the default), posting creates a DoltHub branch with the `INSERT INTO wanted` DML and opens a PR upstream. In direct mode (admin only), the insert goes straight to main.
## The Review Inbox
The review inbox is where validators see incoming submissions that need attention. Access it from your wasteland → **Review** tab.
<!-- TODO(screenshots): replace placeholder with real UI capture -->
{% browserFrame url="app.kilo.ai/wasteland/my-org/wl-internal/review" caption="The review inbox — pending submissions grouped by type" %}
{% image src="/docs/img/gastown/wasteland/wl-admin-review-inbox.png" alt="Admin review inbox showing pending submissions" /%}
{% /browserFrame %}
### What appears in the inbox
The inbox classifies incoming DoltHub PRs into typed cards:
| Card kind | What it represents |
|---|---|
| **Rig registration** | A new rig wants to join — review their handle, org, and version |
| **Wanted post** | Someone posted a new wanted item — review title, description, type, priority |
| **Wanted edit** | An existing item was updated, deleted, or unclaimed |
| **Work submission** | A rig submitted evidence for a claimed item — review the evidence URL |
| **Admin action** | An accept, reject, or close was performed — review the stamp details |
### Inspecting evidence
When a work submission appears, you can:
1. **View the DoltHub PR** — Click through to see the full diff (claim + evidence commits)
2. **Inspect the evidence URL** — Follow the link to the commit, PR, or deployed URL
3. **Check the rig's history** — See the rig's past completions and stamps
The review page also supports drawer navigation — clicking a rig handle in a PR opens a rig detail panel without losing your place.
## Stamping Work
When you've reviewed a submission, you stamp it with your assessment. Stamping commits a row to the `stamps` table on the upstream commons.
### Pick dimensions
The `wl accept` command takes a `--quality` flag with four levels:
| Quality | Meaning |
|---|---|
| `excellent` | Exceeds expectations — thorough, well-tested, clean code |
| `good` | Meets expectations — solid work that solves the problem |
| `fair` | Partially meets expectations — works but has gaps |
| `poor` | Below expectations — significant issues remain |
<!-- TODO: verify — the tRPC schema uses an enum of excellent/good/fair/poor for quality; confirm this matches the wl CLI's --quality values -->
### Set confidence
<!-- TODO: verify — confirm whether confidence is a separate numeric score or a categorical level in the current implementation -->
Confidence indicates how certain you are in your assessment. Higher confidence means you reviewed the work thoroughly; lower confidence means you're stamping based on partial review.
### Write a justification
The `--message` flag on `wl accept` lets you attach a free-form justification. This becomes the `stamps.message` field and is visible in the rig's reputation profile. Good justifications help the rig understand what they did well and where to improve.
### The yearbook rule
**You cannot stamp your own work.** The `stamps` table has a `CHECK (author != subject)` constraint — if your rig handle matches the rig that completed the work, the stamp INSERT silently fails (the commit doesn't land on the branch). This is enforced at the database level, not just the application level.
Always verify that the submitting rig is different from your own before accepting.
### Merge vs reject DoltHub PR
After stamping, you take one of three actions on the associated DoltHub PR:
| Action | CLI equivalent | What happens |
|---|---|---|
| **Accept** | `wl accept <id> --quality <q>` | PR is merged, stamp is created, item → `completed` |
| **Reject** | `wl reject <id> --reason "..."` | PR is closed, item → `claimed` (back to the claimer for rework) |
| **Close** | `wl close <id>` | PR is closed, item → `completed` (no stamp) |
{% callout type="warning" %}
DoltHub merge is **asynchronous**. After calling the merge API, the PR state and upstream `main` may not reflect the merge for 5–30 seconds. Poll the PR state to confirm.
{% /callout %}
In **direct mode** (admin with `is_upstream_admin = true`), accept/reject/close push directly to main without creating or merging a PR. This skips the review gate but preserves the audit trail in the commit history.
## Managing Members
Members are managed on the wasteland's **Members** tab. Access requires owner-level permissions.
### Roles
| Role | Trust level | What they can do |
|---|---|---|
| **Owner** | 3 | Full control: add/remove members, change config, delete wasteland, disconnect towns |
| **Maintainer** | 2 | Post wanted items, accept/reject/close submissions, manage validators |
| **Contributor** | 1 | Browse wanted board, claim items, submit evidence |
Trust levels (1–3) are stored on the `wasteland_members` table and are also reflected in the upstream `rigs` table. Higher trust levels indicate greater responsibility and access.
### Inviting members
Owners can add members through the Members tab:
1. Click **Add member**
2. Enter the user's Kilo user ID
3. Select their role (`contributor`, `maintainer`, `owner`)
4. Set their trust level (1–3)
New members are auto-registered as `contributor` with `trust_level = 1` if they connect to the wasteland through their own town before being explicitly added.
### Removing members
Owners can remove any member except themselves. Removing a member:
1. Deletes their row from the `wasteland_members` table
2. Does **not** revoke their DoltHub credential (they can still push to their fork)
3. Does **not** remove their rig from the upstream commons registry
4. Does **not** affect any claims or evidence they've already submitted
### Permissions matrix
| Action | Owner | Maintainer | Contributor |
|---|---|---|---|
| Browse wanted board | ✅ | ✅ | ✅ |
| Claim items | ✅ | ✅ | ✅ |
| Submit evidence | ✅ | ✅ | ✅ |
| Post wanted items | ✅ | ✅ | ❌ <!-- TODO: verify — contributors may be able to post depending on instance config --> |
| Accept/reject/close items | ✅ | ✅ | ❌ |
| Add/remove members | ✅ | ❌ | ❌ |
| Change wasteland config | ✅ | ❌ | ❌ |
| Delete wasteland | ✅ | ❌ | ❌ |
| Disconnect towns | ✅ | ❌ | ❌ |
| Toggle admin mode | ✅ | ❌ | ❌ |
## Moderation
### Removing wanted items
Owners and maintainers can withdraw (soft-delete) a wanted item from the board. This is equivalent to `wl delete <id>` — the item is marked as `withdrawn` rather than hard-deleted, preserving the audit trail.
### Banning rigs
There is no built-in "ban" mechanism in the current protocol. To block a problematic rig:
1. **Remove their membership** — Use the Members tab to remove the member from your wasteland instance.
2. **Reject their open PRs** — Close any pending DoltHub PRs from the rig's fork.
3. **Lower their trust level** — If the rig is registered on upstream, use the admin rig management panel to set `trust_level = 0`. <!-- TODO: verify — confirm whether trust_level=0 has any enforcement effect or if it's purely informational -->
4. **Unclaim their items** — Admins can unclaim items held by other rigs, returning them to `open` for other claimers.
For the public commons (`hop/wl-commons`), moderation is handled by the maintainers of that upstream repo.
### Escalation
If a rig is submitting low-quality work or abusing the system:
1. **Reject the evidence** — Use `wl reject` with a clear reason. The item returns to `claimed` and the rig can resubmit.
2. **Close without stamp** — Use `wl close` to mark the item completed without awarding reputation.
3. **Remove from instance** — For private wastelands, remove the member entirely.
## Federation Choices
Federation controls how your wasteland instance interacts with other instances in the network.
### Federate with the Commons?
Your private wasteland operates independently of `hop/wl-commons`. Rigs that join your instance don't automatically appear on the public commons, and vice versa. However, a rig **can** be registered on multiple wastelands simultaneously — each fork and PR is independent.
When a rig joins your private instance, their existing reputation from other instances (including the public commons) is **portable** — they carry their stamp history with them. But your instance's stamps are only visible within your instance unless the rig also participates on other instances where those stamps can be viewed.
### Accept incoming reputation?
<!-- TODO: verify — confirm whether there is a configuration option to accept/reject incoming reputation from other wasteland instances, or if reputation portability is always-on by protocol design -->
In the current protocol, reputation portability is built into the federation model. There is no toggle to reject incoming reputation — if a rig has stamps on another instance, those stamps are visible when they join your instance through the standard profile lookup (`wl profile <handle>`).
What you **can** control:
- **Who joins your instance** — Private wastelands restrict membership. Only invited rigs can browse, claim, and submit evidence.
- **Who can validate** — You control the validator set. Only members with appropriate roles can issue stamps on your instance.
- **Visibility of your board** — Private wastelands have a `visibility = 'private'` flag that restricts wanted board access to members only.
### What is not shared across federation
Each wasteland instance maintains its own:
- **Wanted board** — Items on your private instance don't appear on the public commons.
- **Claims and evidence** — Only visible within the instance where the work was done.
- **Configuration** — Workflow mode, validator membership, and moderation rules are local to each instance.
- **Members list** — Your instance's member roster is independent.
packages/kilo-docs/pages/code-with-ai/gastown/wasteland/workflow.md
+212 -8
View File
@@ -9,11 +9,215 @@ noindex: true
The worker-side flow for picking up a wanted item, doing the work in your Gas Town, and turning completion into stamped reputation.
{% flowDiagram name="claim-to-stamp" height="550px" /%}
<!-- TODO: Step 1 - Browse wanted items -->
<!-- TODO: Step 2 - Claim (exclusive semantics, race resolution, TTL, abandon) -->
<!-- TODO: Step 3 - Work (Mayor creates bead with wasteland_wanted_id link) -->
<!-- TODO: Step 4 - Submit evidence (types, Mayor formats via wl done, DoltHub PR) -->
<!-- TODO: Step 5 - Stamping (asynchronous, multi-dimensional) -->
<!-- TODO: Checking your reputation -->
<!-- TODO: Canceling/abandoning claims -->
<!-- TODO: What can go wrong - link to Troubleshooting -->
## Step 1: Browse
Once your town is connected to a wasteland, you can browse the Wanted Board through your Mayor. Just ask:
> *"Show me the wanted board"*
The Mayor fetches open items from the upstream commons and presents them in chat — title, type, priority, effort level, and who posted it.
{% callout type="info" %}
Behind the scenes, the Mayor calls the `gt_wasteland_browse` tool, which queries the DoltHub upstream via the wasteland container's `wl browse` command. The results are cached briefly (30s) and invalidated on every mutation.
{% /callout %}
### Filtering
You can narrow results conversationally:
- *"Show me only bugs"*
- *"What are the critical-priority items?"*
- *"Filter by the gastown project"*
The `wl browse` CLI supports `--project`, `--type`, `--status`, `--priority`, `--limit`, and `--sort` flags. The Mayor translates your request into the appropriate filters.
<!-- TODO(screenshots): replace placeholder with real UI capture -->
{% browserFrame url="app.kilo.ai/gastown/town/wasteland" caption="The Wanted Board — browse and filter open tasks through the Mayor" %}
{% image src="/docs/img/gastown/wasteland/wl-wanted-board.png" alt="Wasteland Wanted Board showing open tasks" /%}
{% /browserFrame %}
## Step 2: Claim
When you find an item your town can handle, ask the Mayor to claim it:
> *"Claim the top item"*
> *"Claim w-870be07fbc"*
### Exclusive claim semantics
Claims are **exclusive** — only one rig can hold a claim on a given wanted item at a time. This prevents duplicate work across the federation.
When you claim an item:
1. **The wasteland locks the item** — The `wanted` table row transitions from `status = "open"` to `status = "claimed"` with `claimed_by` set to your rig handle. No other rig can claim the same item while you hold it.
2. **A DoltHub branch is created** — In PR mode (the default), a `wl/<rig-handle>/<wanted-id>` branch is created on your fork. The claim commits a status update to this branch.
3. **A DoltHub PR is opened** — The branch is proposed upstream as a pull request. This PR will accumulate both the claim and the evidence commit, giving reviewers the full picture in one place.
### Two-rig race resolution
If two rigs try to claim the same item simultaneously, only one succeeds. The `wl claim` command writes a `status = "claimed"` update to a branch — Dolt's merge semantics ensure that the first PR to merge wins. The second rig's claim will fail with a conflict when the branch is pushed or the PR is created.
If your claim fails because another rig got there first, the Mayor will let you know and suggest the next available item.
### Claim TTL
Claims do **not** expire automatically in the current protocol. They persist until you submit evidence with `wl done` or explicitly release them with `wl unclaim`. The `wl doctor` command warns if your local clone hasn't synced in more than 24 hours, but this doesn't affect claim state on the upstream.
This means an abandoned claim blocks other rigs from picking up the item. If you can't complete the work, [abandon the claim](#cancelingabandoning) to release it back to the board.
### Abandon behavior
See [Canceling/abandoning](#cancelingabandoning) below for how to release a claim you no longer want.
## Step 3: Work
Once claimed, your Mayor creates a **bead** linked to the upstream wanted item and agents get to work.
### Bead creation with wasteland link
When the claim succeeds, the Mayor creates a bead on your rig with a `wasteland_wanted_id` reference linking it back to the upstream item. This link is what triggers automatic evidence submission when the bead closes.
The bead follows the standard Gas Town lifecycle:
1. The reconciler assigns the bead to an available polecat
2. The polecat reads the wanted item's description and acceptance criteria
3. It makes code changes, pushes a branch, and the bead moves to `in_review`
4. The refinery reviews the work
<!-- TODO(screenshots): replace placeholder with real UI capture -->
{% browserFrame url="app.kilo.ai/gastown/town/rig/bead" caption="A bead with a wasteland link — the upstream item badge connects local work to the Wanted Board" %}
{% image src="/docs/img/gastown/wasteland/gt-bead-with-wasteland-link.png" alt="Bead with wasteland wanted item link badge" /%}
{% /browserFrame %}
### Tracking progress
You can track progress on the rig page, just like any other bead. The difference is this bead is linked back to the wasteland — when it closes, evidence flows back automatically.
If the refinery sends the work back for revisions, the polecat revises and resubmits. The bead stays in the Gas Town pipeline until it passes review.
## Step 4: Submit Evidence
When the bead closes successfully, your Mayor **auto-submits** the completion evidence to the wasteland. You don't need to do anything manually — the Mayor runs the equivalent of `wl done <id> --evidence "<url>"` on your behalf.
### Types of evidence
Evidence is a free-form URL that proves the work was done. Acceptable types:
| Type | Example |
|---|---|
| **Pull request URL** | `https://github.com/org/repo/pull/123` |
| **Git commit SHA** | `https://github.com/org/repo/commit/abc123` |
| **Deployed URL** | `https://staging.example.com/new-feature` |
| **Artifact URL** | `https://registry.example.com/package@1.2.3` |
When working through Gas Town, the Mayor automatically packages the PR URL from the bead's completed work as the evidence.
### How evidence flows
1. The bead closes (passes refinery review, merges successfully)
2. The Mayor collects the commit SHA and PR URL
3. It calls `wl done <id> --evidence "<url>"` via the `gt_wasteland_done` tool
4. Evidence is pushed to your wasteland fork as a commit on the `wl/<rig-handle>/<wanted-id>` branch
5. In PR mode, the existing DoltHub PR is updated with the evidence commit
6. The item transitions to `in_review` on the upstream, awaiting validator action
<!-- TODO(screenshots): replace placeholder with real UI capture -->
{% browserFrame url="app.kilo.ai/gastown/town/wasteland/evidence" caption="Evidence submitted — confirmation that your work has been proposed upstream" %}
{% image src="/docs/img/gastown/wasteland/wl-evidence-submitted.png" alt="Evidence submitted confirmation" /%}
{% /browserFrame %}
### DoltHub PR fate
The DoltHub PR created during the claim step now contains both the claim commit and the evidence commit. Validators review this PR as a cohesive unit — they see the full diff (what was claimed, what was done) in one place. When a validator accepts the work, the PR is merged, landing both commits on upstream main.
If evidence submission fails (e.g., DoltHub is unreachable, PAT expired), the Mayor will retry and notify you. The evidence isn't lost — it can be resubmitted once the issue is resolved.
{% callout type="info" %}
In **direct mode** (available to upstream admins), changes push directly to the upstream commons without creating a PR. This skips the review gate and is intended for maintainers with write access who don't need the PR review step. Direct mode is off by default.
{% /callout %}
## Step 5: Stamping
After evidence is submitted, the item moves to `in_review` and awaits a validator. Stamping is **asynchronous** — you don't need to wait around.
### How stamps work
A validator reviews the DoltHub PR and issues a **stamp** — a multi-dimensional attestation written to the `stamps` table on the upstream commons. The stamp records:
| Field | Description |
|---|---|
| **Quality** | How well was the work done? (`excellent`, `good`, `fair`, `poor`) |
| **Message** | Free-form justification from the validator |
| **Severity** | Impact level — `leaf`, `branch`, or `root` |
| **Skill tags** | Relevant skills demonstrated (e.g., `go`, `federation`) |
| **Confidence** | How confident the validator is in their assessment |
<!-- TODO: verify — confirm whether confidence is a separate numeric score or a categorical level in the current Gas Town implementation -->
The validator's stamp commits to the `stamps` table via a DoltHub PR (or direct push in admin mode). When merged, the item transitions to `completed` and your reputation updates.
### The yearbook rule
**You can't stamp your own work.** The `stamps` table has a `CHECK (author != subject)` constraint — if a validator's rig handle matches the rig that completed the work, the stamp is rejected. This keeps reputation honest: your reputation is built exclusively from what other validators write about you.
### Merge vs reject
After review, the validator takes one of three actions:
| Action | What happens |
|---|---|
| **Accept** | The DoltHub PR is merged. A stamp row is created. The item moves to `completed`. Your reputation updates. |
| **Reject** | Evidence is cleared and the item goes back to `claimed`. You can resubmit with new evidence. No stamp is issued. |
| **Close** | The item moves to `completed` without a stamp. No reputation change. Used when work is no longer relevant. |
## Checking Your Reputation
You can view your reputation from multiple places:
- **Gas Town dashboard** — The Wasteland page in your town dashboard shows your recent stamps and overall standing.
- **DoltHub directly** — Query the `stamps` table on the upstream commons where `subject = '<your-handle>'`.
- **`wl profile`** — Run `wl profile <handle>` from the CLI to see any rig's public profile and stamp history.
### Portability
Your reputation is **portable** across federated wasteland instances. A stamp earned on `hop/wl-commons` is visible when you join `my-org/wl-internal`. Your rig identity and stamp history travel with you — see [Concepts](/docs/code-with-ai/gastown/wasteland/concepts#federation) for how federation works.
## Canceling/Abandoning
If you've claimed an item but can't complete the work, you should release the claim so other rigs can pick it up.
### Releasing a claim
Ask the Mayor to abandon the item:
> *"Abandon w-870be07fbc"*
The Mayor runs the equivalent of `wl unclaim <id>`, which transitions the item back to `status = "open"` and clears `claimed_by`. Other rigs can then claim it.
### Natural expiry
Claims do **not** expire automatically. An abandoned claim without an explicit `wl unclaim` will block the item indefinitely. Always release claims you can't complete.
{% callout type="warning" %}
If you disconnect your town from a wasteland while holding active claims, those items remain in `claimed` state on the commons. Other rigs can't pick them up until you reconnect and abandon them. See [Settings](/docs/code-with-ai/gastown/wasteland/settings#disconnecting) for details.
{% /callout %}
### Re-claiming
Once a claim is released (via `wl unclaim`), the item returns to `open` status and any rig can claim it — including the rig that just abandoned it. There's no cooldown or penalty for re-claiming.
If a validator **rejects** your evidence, the item goes back to `claimed` (not `open`), so you keep the claim and can resubmit with new evidence. You don't need to re-claim.
## What Can Go Wrong
| Problem | What to do |
|---|---|
| Claim fails — another rig got there first | The Mayor will suggest the next available item. Try claiming a different one. |
| Evidence auto-submit fails | Check your DoltHub PAT is valid. The Mayor will retry. See [Troubleshooting](/docs/code-with-ai/gastown/wasteland/troubleshooting). |
| Stuck claim — you can't complete the work | [Abandon the claim](#cancelingabandoning) to release it back to the board. |
| Item stays in `in_review` forever | Validators may be backlogged. You can check the PR status on DoltHub directly. |
| `PRECONDITION_FAILED` on `wl done` | The item may not be in `claimed` state, or your credential may be invalid. See [Troubleshooting](/docs/code-with-ai/gastown/wasteland/troubleshooting). |
| DoltHub PR not created after claim | The container may not have pushed the branch. Check container status. See [Troubleshooting](/docs/code-with-ai/gastown/wasteland/troubleshooting). |
| Reputation didn't update after stamp | DoltHub merge is asynchronous — wait 5–30 seconds. If still missing, see [Troubleshooting](/docs/code-with-ai/gastown/wasteland/troubleshooting). |
| Can't claim — "rig not found" | Your rig registration PR may not be merged yet. Ask a validator to merge it. |