Hive Mind Task-Quality Lint Pack

Hive Mind Task-Quality Lint Pack

# Hive Mind Task-Quality Lint Pack

> **Version:** 1.0.0  
> **Published:** 2026-05-04  
> **Purpose:** Machine-readable rules + human-readable rewrite guidance for Hive Mind task generation. Prevents common failure modes that lead to task refusals, stale assignments, unverifiable deliverables, and privacy leakage.

---

## How to Use This Pack

**If you write Hive Mind tasks:** Run each draft task through the 10 rules below before publishing. If any rule triggers, apply the rewrite action before issuing the card.

**If you review task completions:** Use the pass conditions as acceptance criteria. A task that fails a lint rule at generation time will almost certainly produce unverifiable or low-value output.

**If you build tooling:** The [JSON Rules Block](#json-rules-block) at the bottom is designed for prompt-pack injection or automated pre-publish checks.

---

## Lint Rules

### Rule 1 — Stale Project Reference

| Field | Value |
|-------|-------|
| **ID** | `HIVE-LINT-001` |
| **Label** | Stale Project Reference |
| **Severity** | `error` |
| **Trigger** | Task references a project, repository, endpoint, or initiative that has been archived, deprecated, sunset, or not updated in >90 days without acknowledging the staleness. |
| **Pass Condition** | All referenced projects are confirmed active OR the task explicitly states the goal is to revive/audit the stale reference. |
| **Rewrite Action** | Replace the stale reference with a currently-active equivalent, or reframe the task as "audit whether [project] is still viable and produce a status memo." |
| **Network-Value Rationale** | Stale references generate wasted contributor hours and produce deliverables that can't merge into live systems — net-negative PFT value. |

---

### Rule 2 — Missing Source Signal

| Field | Value |
|-------|-------|
| **ID** | `HIVE-LINT-002` |
| **Label** | Missing Source Signal |
| **Severity** | `error` |
| **Trigger** | Task asks a contributor to produce analysis, research, or a recommendation without specifying what data, document, or observable input they should use. |
| **Pass Condition** | Task names at least one concrete, accessible input source (public URL, dataset, on-chain data, published spec) OR explicitly states "use your own sourcing and cite all inputs." |
| **Rewrite Action** | Add a "Sources" or "Inputs" field listing the minimum data the contributor should consult, or add an explicit open-sourcing instruction with citation requirements. |
| **Network-Value Rationale** | Unsourced tasks produce opinion-posts rather than verifiable signal — reviewers cannot distinguish quality from noise. |

---

### Rule 3 — Unclear Deliverable

| Field | Value |
|-------|-------|
| **ID** | `HIVE-LINT-003` |
| **Label** | Unclear Deliverable |
| **Severity** | `error` |
| **Trigger** | Task lacks a concrete, verifiable output format. Phrases like "look into," "explore," "think about," or "help with" without a defined artifact. |
| **Pass Condition** | Task specifies the exact deliverable type (memo, code PR, config file, published URL, spreadsheet, diagram) AND its minimum acceptance criteria. |
| **Rewrite Action** | Replace vague verbs with "Produce [artifact type] that contains [minimum sections/elements]. Submit as [format] at [location]." |
| **Network-Value Rationale** | Unclear deliverables make review subjective and create disputes over task completion — they erode reviewer trust and slow the reward cycle. |

---

### Rule 4 — Duplicate or Already-Shipped Risk

| Field | Value |
|-------|-------|
| **ID** | `HIVE-LINT-004` |
| **Label** | Duplicate / Already-Shipped |
| **Severity** | `warning` |
| **Trigger** | Task describes work that overlaps >70% with a previously completed task, an already-merged PR, or a published artifact — without acknowledging the prior work or explaining what's new. |
| **Pass Condition** | Task either (a) links prior work and scopes the delta explicitly, or (b) is confirmed net-new after a search of completed tasks. |
| **Rewrite Action** | Add "Prior art: [link/reference]. This task extends that work by [specific delta]." If no delta exists, withdraw the task. |
| **Network-Value Rationale** | Duplicate tasks dilute PFT rewards across redundant work and signal poor network coordination to contributors. |

---

### Rule 5 — Ambiguous Evidence Standard

| Field | Value |
|-------|-------|
| **ID** | `HIVE-LINT-005` |
| **Label** | Ambiguous Evidence Standard |
| **Severity** | `warning` |
| **Trigger** | Task asks for "proof," "evidence," or "verification" without defining what constitutes acceptable evidence (on-chain tx, screenshot, public URL, hash, attestation). |
| **Pass Condition** | Task includes a "Verification" section that names the exact evidence type, format, and where it should be submitted. |
| **Rewrite Action** | Add: "Verification: Submit [evidence type] at [location]. Acceptable formats: [list]. Reviewer will confirm by [check method]." |
| **Network-Value Rationale** | Ambiguous evidence standards create reviewer inconsistency — identical work gets approved or rejected depending on who reviews, undermining network credibility. |

---

### Rule 6 — Overbroad Scope

| Field | Value |
|-------|-------|
| **ID** | `HIVE-LINT-006` |
| **Label** | Overbroad Scope |
| **Severity** | `warning` |
| **Trigger** | Task contains more than 3 distinct deliverables, spans more than 2 functional domains, or would reasonably take >40 hours for a skilled contributor. |
| **Pass Condition** | Task is scoped to a single coherent deliverable achievable in ≤20 hours, OR is explicitly labeled as a multi-phase epic with individually-completable sub-tasks. |
| **Rewrite Action** | Decompose into 2–4 focused sub-tasks, each with its own deliverable and verification criteria. Link them sequentially if order matters. |
| **Network-Value Rationale** | Overbroad tasks attract partial completions, create review bottlenecks, and make reward calibration nearly impossible. |

---

### Rule 7 — Unreviewable Collaboration Ask

| Field | Value |
|-------|-------|
| **ID** | `HIVE-LINT-007` |
| **Label** | Unreviewable Collaboration Ask |
| **Severity** | `error` |
| **Trigger** | Task requires coordination with a specific unnamed party, access to a private system, or participation in a non-public channel — making independent review impossible. |
| **Pass Condition** | All collaboration requirements reference publicly-observable touchpoints, OR the task provides an alternative verification path that doesn't require reviewer access to private systems. |
| **Rewrite Action** | Replace private collaboration requirements with publicly-verifiable outputs: "Produce a summary document of the coordination outcome, published at [public location], that a reviewer can assess independently." |
| **Network-Value Rationale** | Tasks that can't be independently reviewed break the trustless verification model — they require social trust that doesn't scale. |

---

### Rule 8 — Missing PFT Value Rationale

| Field | Value |
|-------|-------|
| **ID** | `HIVE-LINT-008` |
| **Label** | Missing PFT Value Rationale |
| **Severity** | `warning` |
| **Trigger** | Task does not explain how the deliverable creates value for the Post Fiat network specifically. Generic "this is useful" framing without network-specific benefit. |
| **Pass Condition** | Task includes a 1–2 sentence value statement connecting the deliverable to a specific network function: governance, liquidity, contributor tooling, protocol development, adoption, or signal quality. |
| **Rewrite Action** | Add: "Network value: This task improves [specific network function] by [mechanism], which [measurable or observable outcome]." |
| **Network-Value Rationale** | Tasks without network-value rationale attract mercenary completions optimized for reward extraction rather than network improvement. |

---

### Rule 9 — Wrong Contributor Archetype

| Field | Value |
|-------|-------|
| **ID** | `HIVE-LINT-009` |
| **Label** | Wrong Contributor Archetype |
| **Severity** | `info` |
| **Trigger** | Task requires skills or access that the target contributor pool demonstrably lacks (e.g., asking community writers to deploy smart contracts, or asking developers to produce marketing copy). |
| **Pass Condition** | Task skill requirements align with the archetype of contributors who will see and claim it, OR the task explicitly states the required skill set and accepts that the pool may be limited. |
| **Rewrite Action** | Either (a) adjust scope to match available contributor skills, or (b) add a "Required Skills" field and accept narrower claim rates. |
| **Network-Value Rationale** | Mismatched tasks create frustration, low completion rates, and poor-quality outputs that waste reviewer bandwidth. |

---

### Rule 10 — Privacy Leakage

| Field | Value |
|-------|-------|
| **ID** | `HIVE-LINT-010` |
| **Label** | Privacy Leakage |
| **Severity** | `critical` |
| **Trigger** | Task text contains or requires exposure of: wallet addresses tied to real identities, contributor handles in non-public contexts, private repository URLs, internal system credentials, personal contact information, or non-public financial data. |
| **Pass Condition** | Task contains zero PII, zero private URLs, zero wallet-to-identity mappings. All references use anonymized placeholders or public-only identifiers. |
| **Rewrite Action** | Strip all private identifiers. Replace with role-based references ("the submitting contributor," "the target repository") or anonymized placeholders. If the task fundamentally requires private data, it should not be issued as a public Hive Mind task. |
| **Network-Value Rationale** | Privacy leakage exposes contributors to doxxing, regulatory risk, and targeted attacks — it's an existential threat to pseudonymous participation in the network. |

---

## Before / After Task Rewrites

Each example shows a failing task and its corrected version. All content is anonymized — no real handles, wallets, repos, or private links.

---

### Example 1 — Stale Project Reference (HIVE-LINT-001)

**BEFORE (fails):**
> Write documentation for the NetworkBridge v1 API endpoints. Reference the existing integration guide in the team wiki.

**Problem:** NetworkBridge v1 was deprecated 6 months ago. The wiki page hasn't been updated since. A contributor would produce documentation for a dead system.

**AFTER (passes):**
> Audit the current state of the NetworkBridge project. Deliverable: A status memo (≤500 words) confirming whether the project is active, archived, or superseded. If active, identify which version is current and list its public API endpoints. If deprecated, recommend whether documentation effort should redirect to the successor system. Submit as a published Markdown document.

---

### Example 2 — Missing Source Signal (HIVE-LINT-002)

**BEFORE (fails):**
> Research the competitive landscape for on-chain signal marketplaces and produce a comparison matrix.

**Problem:** No input sources specified. Contributor doesn't know whether to use public websites, whitepapers, on-chain data, or something else. Output quality will be random.

**AFTER (passes):**
> Produce a comparison matrix of on-chain signal marketplaces. Sources: Use only publicly-accessible documentation, published whitepapers, and on-chain data from block explorers. Minimum coverage: 4 active projects. Columns: name, chain, signal type, pricing model, contributor count (if public), last activity date. Deliverable: Markdown table with source URLs cited per cell. Submit as a published Gist or equivalent public document.

---

### Example 3 — Unclear Deliverable (HIVE-LINT-003)

**BEFORE (fails):**
> Help improve the onboarding experience for new contributors.

**Problem:** "Help improve" is not a deliverable. No artifact, no format, no acceptance criteria. A contributor could spend 2 hours or 200 hours and still not know if they're done.

**AFTER (passes):**
> Produce a contributor onboarding checklist (Markdown format, ≤1 page) covering: account setup, first task claim, submission process, and review expectations. Include one "common mistakes" section with ≥3 entries. Verification: Submit as a public URL. Reviewer confirms all 4 sections are present and instructions are accurate against current system behavior.

---

### Example 4 — Duplicate / Already-Shipped (HIVE-LINT-004)

**BEFORE (fails):**
> Create a task template that standardizes how Hive Mind cards are written.

**Problem:** A task template was published 3 weeks ago and is already in active use. This duplicates shipped work without acknowledging it.

**AFTER (passes):**
> Extend the existing published task template (reference: [public URL of existing template]) with two new sections: (1) a "Verification" section template with example evidence types, and (2) a "Network Value" section template with fill-in prompts. Prior art: The base template was published on [date] and covers structure, scope, and deliverable format. This task adds only the verification and value-rationale layers. Submit as a PR or revision to the existing public document.

---

### Example 5 — Ambiguous Evidence Standard (HIVE-LINT-005)

**BEFORE (fails):**
> Deploy the monitoring dashboard and prove it works.

**Problem:** "Prove it works" is not a verification standard. Screenshot? Live URL? Uptime log? Test results? The contributor will guess; the reviewer will disagree.

**AFTER (passes):**
> Deploy the monitoring dashboard to the staging environment. Verification: Submit (1) the public URL of the running dashboard, (2) a screenshot showing ≥1 hour of live data ingestion, and (3) a 3-line summary of metrics displayed. Reviewer will load the URL and confirm data is updating in real-time.

---

### Example 6 — Overbroad Scope (HIVE-LINT-006)

**BEFORE (fails):**
> Build a complete contributor reputation system: design the scoring algorithm, implement the smart contract, create the frontend dashboard, write documentation, and deploy to mainnet.

**Problem:** This is 5 distinct workstreams spanning algorithm design, smart contract development, frontend engineering, technical writing, and DevOps. No single contributor can credibly deliver all five, and partial completion is unverifiable.

**AFTER (passes):**
> **Task 1 of 4:** Design the contributor reputation scoring algorithm. Deliverable: A specification document (≤2000 words) covering input signals, weighting logic, decay function, and edge cases. Include ≥3 worked examples showing score calculations. Submit as a public Markdown document. Verification: Reviewer confirms all specified sections are present and worked examples are mathematically consistent.

*(Subsequent tasks for implementation, frontend, and deployment issued separately after Task 1 is accepted.)*

---

### Example 7 — Unreviewable Collaboration Ask (HIVE-LINT-007)

**BEFORE (fails):**
> Coordinate with the core team on Discord to align the token economics model, then confirm alignment was reached.

**Problem:** A reviewer cannot access private Discord conversations to verify that coordination happened or that alignment was genuine. This requires social trust, not evidence.

**AFTER (passes):**
> Produce a token economics alignment memo (≤1000 words) summarizing: (1) the current published model parameters, (2) ≥2 open questions or disagreements identified in public forum discussions, and (3) a proposed resolution for each with rationale. Submit as a public document. Verification: Reviewer confirms all open questions are sourced from public discussions and proposed resolutions are internally consistent. Note: This task does not require private coordination — it synthesizes publicly-available information.

---

### Example 8 — Missing PFT Value Rationale (HIVE-LINT-008)

**BEFORE (fails):**
> Write a blog post about decentralized work and publish it on a personal blog.

**Problem:** No connection to PFT network value. A contributor could write about any decentralized work platform and fulfill the letter of the task without creating network-specific benefit.

**AFTER (passes):**
> Write a 600–1000 word article explaining how task-based contribution networks solve the cold-start problem for on-chain coordination. The article must reference the Post Fiat task model specifically and explain ≥2 mechanisms by which task completion generates network value (e.g., signal quality improvement, contributor skill verification). Publish at a publicly-accessible URL. Network value: This task improves network adoption by creating discoverable educational content that reduces onboarding friction for prospective contributors.

---

### Example 9 — Wrong Contributor Archetype (HIVE-LINT-009)

**BEFORE (fails):**
> Implement a Rust-based transaction parser for the XRP Ledger with full test coverage.

**Problem:** Issued to a general contributor pool that is predominantly writers, researchers, and community managers. Rust + XRPL parsing requires specialized systems programming skills that <5% of the pool possesses.

**AFTER (passes):**
> **Required Skills:** Rust (intermediate+), familiarity with XRP Ledger transaction formats. Implement a Rust-based transaction parser that handles Payment, TrustSet, and OfferCreate transaction types. Deliverable: Public repository with source code, ≥10 unit tests covering happy-path and malformed-input cases, and a README with build instructions. Verification: Reviewer clones repo, runs `cargo test`, confirms all tests pass. Note: This task targets contributors with systems programming experience — expect a narrow claim pool.

---

### Example 10 — Privacy Leakage (HIVE-LINT-010)

**BEFORE (fails):**
> Review the transaction history of wallet rXYZ123...789 to analyze the contributor's on-chain activity patterns and assess their commitment level based on holdings and transaction frequency.

**Problem:** Links a specific wallet address to contributor assessment, creating a wallet-to-behavior mapping that could be used for doxxing or targeted attacks. Exposes private financial data.

**AFTER (passes):**
> Produce an anonymized framework (≤800 words) for assessing on-chain contribution commitment using publicly-observable network metrics. The framework must: (1) define 3–5 observable signals that indicate sustained participation (e.g., task completion frequency, memo cadence, governance participation), (2) propose thresholds for "active," "intermittent," and "inactive" classifications, and (3) explicitly exclude wallet balance or transaction volume as signals (privacy rationale: these create doxxing vectors). Submit as a public document. Verification: Reviewer confirms no specific wallets, handles, or identifiable data appear anywhere in the deliverable.

---

## JSON Rules Block

```json
{
  "schema_version": "1.0.0",
  "pack_id": "hive-mind-task-quality-lint",
  "published": "2026-05-04",
  "rules": [
    {
      "id": "HIVE-LINT-001",
      "label": "Stale Project Reference",
      "severity": "error",
      "trigger": "Task references a project, repo, endpoint, or initiative that is archived, deprecated, or inactive >90 days without acknowledging staleness.",
      "pass_condition": "All referenced projects are confirmed active, OR task explicitly scopes work as a staleness audit.",
      "fix": "Replace stale reference with active equivalent, or reframe as an audit/status-check task."
    },
    {
      "id": "HIVE-LINT-002",
      "label": "Missing Source Signal",
      "severity": "error",
      "trigger": "Task requests analysis or research without specifying input data, documents, or observable sources.",
      "pass_condition": "Task names ≥1 concrete accessible input source, OR explicitly states open-sourcing with citation requirements.",
      "fix": "Add a Sources/Inputs field listing minimum data to consult, or add explicit open-sourcing instruction with citation requirements."
    },
    {
      "id": "HIVE-LINT-003",
      "label": "Unclear Deliverable",
      "severity": "error",
      "trigger": "Task lacks concrete output format. Uses vague verbs: explore, look into, think about, help with.",
      "pass_condition": "Task specifies exact deliverable type and minimum acceptance criteria.",
      "fix": "Replace vague verbs with: Produce [artifact type] containing [minimum elements]. Submit as [format] at [location]."
    },
    {
      "id": "HIVE-LINT-004",
      "label": "Duplicate / Already-Shipped",
      "severity": "warning",
      "trigger": "Task overlaps >70% with a previously completed task or published artifact without acknowledging prior work.",
      "pass_condition": "Task links prior work and scopes the delta, OR is confirmed net-new.",
      "fix": "Add: Prior art: [reference]. This task extends by [specific delta]. If no delta exists, withdraw."
    },
    {
      "id": "HIVE-LINT-005",
      "label": "Ambiguous Evidence Standard",
      "severity": "warning",
      "trigger": "Task asks for proof/evidence/verification without defining acceptable evidence type, format, or submission location.",
      "pass_condition": "Task includes a Verification section naming exact evidence type, format, and submission method.",
      "fix": "Add: Verification: Submit [evidence type] at [location]. Acceptable formats: [list]. Reviewer confirms by [method]."
    },
    {
      "id": "HIVE-LINT-006",
      "label": "Overbroad Scope",
      "severity": "warning",
      "trigger": "Task contains >3 distinct deliverables, spans >2 functional domains, or would take >40 hours.",
      "pass_condition": "Single coherent deliverable achievable in ≤20 hours, OR explicitly labeled multi-phase epic with sub-tasks.",
      "fix": "Decompose into 2-4 focused sub-tasks with individual deliverables and verification criteria."
    },
    {
      "id": "HIVE-LINT-007",
      "label": "Unreviewable Collaboration Ask",
      "severity": "error",
      "trigger": "Task requires coordination via private channels or access to non-public systems, making independent review impossible.",
      "pass_condition": "All requirements reference publicly-observable touchpoints, OR alternative verification path exists.",
      "fix": "Replace private collaboration with publicly-verifiable outputs. Require a published summary document reviewable without private access."
    },
    {
      "id": "HIVE-LINT-008",
      "label": "Missing PFT Value Rationale",
      "severity": "warning",
      "trigger": "Task does not explain how the deliverable creates value for the Post Fiat network specifically.",
      "pass_condition": "Task includes 1-2 sentence value statement connecting deliverable to a specific network function.",
      "fix": "Add: Network value: This task improves [network function] by [mechanism], which [observable outcome]."
    },
    {
      "id": "HIVE-LINT-009",
      "label": "Wrong Contributor Archetype",
      "severity": "info",
      "trigger": "Task requires skills or access the target contributor pool demonstrably lacks.",
      "pass_condition": "Skill requirements align with contributor pool, OR task states required skills and accepts narrow claim rates.",
      "fix": "Adjust scope to match available skills, or add Required Skills field and accept narrower pool."
    },
    {
      "id": "HIVE-LINT-010",
      "label": "Privacy Leakage",
      "severity": "critical",
      "trigger": "Task contains or requires: wallet-to-identity mappings, private repo URLs, credentials, personal contact info, non-public financial data, or contributor handles in non-public contexts.",
      "pass_condition": "Zero PII, zero private URLs, zero wallet-to-identity mappings. All references use anonymized placeholders or public-only identifiers.",
      "fix": "Strip all private identifiers. Use role-based references or anonymized placeholders. If task requires private data, do not issue publicly."
    }
  ]
}
```

---

## Quick Reference for Task Writers

**Before you publish a Hive Mind task, check:**

1. **Is everything I reference still alive?** → No stale projects, dead links, or deprecated systems.
2. **Did I tell them where to look?** → Name your input sources or say "source it yourself and cite everything."
3. **Would a stranger know when they're done?** → Specify the artifact, format, and minimum contents.
4. **Has this already been done?** → Search completed tasks. If extending prior work, say so.
5. **Can a reviewer verify without trusting me?** → Define evidence type, format, and check method.
6. **Can one person actually do this?** → If it's >20 hours or >2 domains, split it.
7. **Can it be reviewed without private access?** → If verification requires a private channel, redesign the output.
8. **Why does the network care?** → State the specific PFT function this improves.
9. **Will the right people see this?** → Match skills to your contributor pool or label it specialized.
10. **Is anyone exposed?** → Zero wallets, zero handles, zero private links. If in doubt, anonymize.

**Severity guide:**
- `critical` — Task must not ship. Privacy/security risk.
- `error` — Task will likely be refused or produce unverifiable output. Fix before publishing.
- `warning` — Task may succeed but has structural weakness. Fix if possible.
- `info` — Awareness item. Task is valid but could be improved.

---

*This lint pack is designed for the Post Fiat Hive Mind task system. It contains no private data, no contributor identifiers, and no wallet addresses. All examples are synthetic and anonymized.*