Project overview

Role Sole founder & builder — product design, front end, back end, launch, daily maintenance

Scenario

Hong Kong university study recruitment is scattered across department sites, social media, chat groups, and offline posters. Researchers lack a continuous way to publish, review applicants, schedule sessions, record compensation, and build reputation; participants must repeatedly compare fragmented eligibility, timing, and reward information.

Product strategy

I designed one operating flow for three roles: researchers publish studies, manage time slots, and review applicants; participants browse, enrol, complete studies, and exchange ratings; administrators govern external sources and review submissions. The Agent extracts structured evidence from source pages and posters, detects freshness, duplicates, and publishing risks, then routes proposals to review queues for an administrator to decide.

Evaluation

A fixed 2026-07-04 production snapshot records 14 Agent runs and 31 review suggestions: 27 were closed, including 22 accepted and 5 rejected. A compensation-amount error was traced to field semantics and became a permanent amount-decomposition rule and policy gate.

Outcome and current stage

The live platform has 81 managed studies (41 published, 38 completed, 2 cancelled), 20 enabled sources, 11 official domains, and 54 platform profiles. The next product stage is B2B outreach to university laboratories and research teams.

My contribution

Study posting + time-slot scheduling + enrolment review for researchers
Browse / filter / sign-up / rating for participants
Full trilingual i18n (EN / 繁中 / 简中)
External Study Ops Agent with a layered autonomy ladder: L1 shadow → L1.5 cross-check → L1.6 Codex replacement check → L2 proposal queue → L3 guarded write (≤1 pending item per queue per run)
Multi-queue agent: one external entry, internal supervisor + four workers (new_study_lead / published_change / source_candidate / seed_candidate), each bounded to a specific Admin pending table
Scheduled guarded review: a daily VPS cron (22:05 UTC) runs in L1 shadow mode, emits read-only evidence, and routes any production change through Admin review
Production Explore truth source, quality workbench, section-level evidence, signup freshness, visual/OCR/QR review, and a feedback-audit ledger

Technical evidence

Agent safety model: every queue proposal passes a deterministic evaluateQueueProposalPolicy() gate that stamps writeEligible; L1 only writes local noProductionWrite=true reports; autonomy stops at Admin pending queues — experiments, source registry, and approve/reject stay human-reviewed
Truth discipline: published experiments in Production Explore remain authoritative; the legacy pipeline, source/seed discovery, and agent shadow reports feed candidates into Admin review
Evaluation & readiness gates: daily-cron evidence distinguishes real_cron from manual runs; L3 readiness requires ≥10 reviewed proposals, ≥80% acceptance, zero stale/bad-source false positives, and no production-write incident over 30 days
Failure→gate discipline: a proposal that mistook an HKD 80 baseline for the total compensation became a permanent compensation-component policy check, downgrading that class to report-only
Reasoner reliability: the Gemini reasoner returns structured JSON; invalid output or failure falls back to a deterministic read-only reasoner, while the policy layer retains execution authority
Self-hosted Supabase (auth + Postgres + maintenance) + Cloudflare for edge acceleration and abuse protection; sustained solo through 153 merged PRs (latest #158, production promotion verified 2026-08-25)

From a pipeline to a harness

External study collection isn't a one-off cold start — recruitment pages expire, forms close, one aggregate page hosts many studies, and the legacy pipeline can misjudge sources or duplicates. Letting an agent write the production database directly is too risky, so the agent is wrapped in a harness: policy gates, a truth source, a quality workbench, and Admin review decide what's actually executable.

The autonomy ladder

Autonomy advances in layers: L1 shadow (local reports only, noProductionWrite=true) → L1.5 cross-check → L1.6 Codex replacement check → L2 proposal queue → L3 guarded write, at most one pending item per queue per run. Each rung has its own gate; experiments, the source registry, and approve/reject remain under human review.

Multi-queue design and truth discipline

One external entry feeds a supervisor that splits work across four workers — new_study_lead, published_change, source_candidate, and seed_candidate — each assigned to a specific Admin pending table. A deterministic evaluateQueueProposalPolicy() gate grants write eligibility.

Published experiments in Production Explore remain authoritative. The legacy pipeline, source/seed discovery, and agent shadow reports contribute candidates through the Admin review path.

A failure that became a gate

One proposal mistook an HKD 80 baseline for the total compensation, ignoring a second optional HKD 80 follow-up. The fix wasn't a one-off correction — the policy gate gained a compensation-component semantic check that downgrades that whole class to report-only. A failure turned into a reusable gate, which is the point of the harness.

Daily guarded review

A VPS cron runs the L1 shadow daily at 22:05 UTC and emits read-only evidence. A separate checker distinguishes scheduled runs from manual ones; three consecutive days of passing real-cron evidence with zero policy violations opens an L2 readiness review, while production changes continue through Admin approval.