Use live marketplace proof for landing page task examples

[jarlyn95]

Summary

The landing page currently relies on static example copy for the work marketplace. Even after refreshing the examples manually, the page can drift out of date again as task amounts, proof requirements, verification rules, and category mix change in the app.

A useful next landing-page enhancement would be to make the public marketplace proof on the homepage data-backed: show live or periodically refreshed task examples and aggregate marketplace stats derived from Gibwork's public task data.

Problem

Visitors evaluating Gibwork need quick proof that the marketplace is active and funded. Static examples help, but they become stale and create maintenance work:

• task amounts can change;
• tasks can close;
• verified-only requirements can change;
• categories shift over time;
• metadata copy can lag behind the actual product.

This weakens the first impression because the landing page is supposed to explain the current product, not a snapshot from a previous campaign.

Proposed Enhancement

Add a small data-backed marketplace proof layer to the landing page:

1. Fetch or generate a curated set of public open tasks for the "Looking for Work" examples.
2. Display high-signal metadata for each example:
   • task title;
   • category;
   • reward amount and token;
   • proof requirement summary;
   • verified-only status;
   • deep link to the task.
3. Add a compact stats row near the worker-facing section with values such as:
   • open funded tasks;
   • available rewards;
   • number of categories represented;
   • highest current open reward.
4. Fall back to checked-in static examples if the public task endpoint is unavailable during build.

Implementation Sketch

A conservative implementation could keep the homepage static while still reducing drift:

• Add a small helper, for example lib/marketplace-proof.ts, that maps raw public task data into a stable TaskProof shape.
• Use a curated allowlist or simple ranking rules so low-quality/social-only tasks do not dominate the homepage.
• Keep the rendered component simple and consistent with the existing LookingFor UI.
• Include fallback data in the repo so production builds are resilient.

The output shape can stay intentionally small:

type TaskProof = {
  title: string;
  amount: number;
  token: "usdc" | string;
  category: string;
  proof: string;
  verifiedOnly: boolean;
  href: string;
};

Acceptance Criteria

• The worker-facing task examples link to current public Gibwork tasks.
• Closed or unfunded tasks are not shown.
• Verified-only tasks are clearly marked.
• The component still renders when the task API is unavailable.
• The implementation has a deterministic test for ranking/filtering task examples.
• Metadata and homepage copy remain aligned with funded tasks, open-source bounties, and Solana/onchain payouts.

Why This Helps

This gives Gibwork stronger social proof with less manual maintenance. It also reinforces the product's actual value proposition: funded public work, task proof, creator review, and wallet-based payouts.

Related Task Context

This issue is submitted for the funded Gibwork task: "Improve Gibwork Landing Page or Submit a GitHub Enhancement".

Related implementation PR for making the current examples actionable: #117

[jarlyn95]

Implementation/proof update for the Gibwork 350 USDC website task:

• Companion PR Make landing page task examples actionable #117 makes landing-page task examples actionable.
• Follow-up PR Clarify task and bounty submission flow #93 further clarifies bounty/task submission flow, updates live task examples, adds linked proof metadata, and refreshes site description copy.
• PR Clarify task and bounty submission flow #93 current head da952c145e22397bf8df8b5a00d91702e728a907 has local npm run build verification documented here: Clarify task and bounty submission flow #93 (comment)

These links provide public reviewable evidence for the proposed live marketplace proof improvement.