← product

Family × PorchHearth — kids chores-for-hire (design doc, COUNSEL-GATED)

Status: DESIGN ONLY — NO CODE either side until (a) Sandon's explicit go-ahead AND (b) counsel review. Both HJ and PH agreed (crosstalk 2026-07-25): a joint design doc is the first artifact, counsel is the second, and no kid-facing or payout code is written before both. This is that doc. Requested 2026-07-25.

What it is

Household + neighborhood chores-for-hire where kids earn real credits. PH owns the two-sided marketplace (a Need = a household posting a chore with offeredPriceCents already exists — the demand side is their best-tested area). HJ's Family layer is where a child sees available chores and where earned credit is attributed to them, tied to the existing family points/chores.

The non-negotiable shape (payment rails force it)

PH flagged the constraint up front, and it decides the whole design:

  • Stripe Connect requires an 18+ account holder. A kid cannot hold a payout account.
  • Therefore: the parent's household is the payee; the credit is attributed to the child inside it. Payout custody sits with the adult by construction, not by policy. Build it this way from line one — it is the only shape the rails allow.
  • PH's HouseholdMemberRole.TEEN is currently a stub (declared, no behavior). Any age-gating / restricted visibility / parent-approval is net-new and must be explicit, not assumed.

Safety model (PH owns marketplace trust; HJ owns the family gate)

Bright lines to design against — these are the counsel questions, stated concretely:

  1. Parent approval per job — no child accepts/starts a chore without a parent approving that specific job. Not a global toggle.
  2. No unsupervised child↔stranger contact. Neighborhood chores for a minor imply an adult in the loop; the design must make "who the kid is physically with" a first-class, parent-controlled field — or restrict to known/vetted households only.
  3. Payout custody = parent. Money lands in the parent household account; the child sees an attributed credit, redeemable per family rules (ties to family_rewards).
  4. Vetting / background posture for the demand side (who can hire a kid) is PH's marketplace responsibility; HJ renders only what PH marks safe-for-minors.
  5. Age floors + disclosures — counsel sets the minimum age, jurisdictional child-labor considerations, and the parental-consent record.
  6. Auditability — every kid-facing money event is parent-visible (the child-view hub is the natural surface) and logged.

Split of responsibilities

  • PH (marketplace): the Need/chore listings, who may hire, trust/safety + vetting, Stripe Connect payout to the parent household, a safe_for_minors/eligibility signal, and a read endpoint HJ consumes (default-OFF, opt-in, PII-safe — same shape as getaways/services).
  • HJ (family): the per-child opt-in (the kids_chores key is already reserved in family_community_optins, migration 583), the parent-approval-per-job gate, the child-facing browse (filtered to safe_for_minors), attributing earned credit into family points/rewards, and parent-visible audit in the child-view hub.

Sequence (nothing skips a gate)

  1. ✅ This design doc.
  2. ⏳ Sandon's explicit go-ahead to pursue it.
  3. ⏳ Counsel review of the safety model + payout-custody + age/consent, against something concrete (this doc + PH's trust model).
  4. Only then: PH contract for the read endpoint + eligibility signal → HJ consumer + parent-approval flow → credit attribution. Ship behind the opt-in, default OFF.

Open questions for counsel / Sandon

  • Minimum age; which jurisdictions; parental-consent record shape.
  • "Neighborhood" (stranger households) vs "known circle only" for v1 — the latter is dramatically lower risk.
  • Whether real money at all in v1, or start with intra-family chores→credits (no external marketplace, no Stripe, no strangers) as a safe first step that proves the attribution mechanic before opening the neighborhood.

⚠️ Credit interchangeability is its OWN gated decision (PH caution, 2026-07-25)

HJ family points and PH neighborhood credits are two separate allowance ledgers and must stay that way by default. The moment a credit earned in one product can be spent or settled in the other, it stops being two ledgers and becomes a currency with two issuers — very hard to walk back once families hold balances, and a conversation neither HJ nor PH has had with Sandon. Do NOT build toward interchange by accident.

  • Shipped intra-family chores (migration 584) touch ONLY HJ's own points — no PH link.
  • PH's chores are internal, JWT-guarded at the class level with specs asserting no public/throttle/proxy guard — structurally unexposable.
  • If a "mirror" is ever wanted: one-directional, read-only (HJ displays a PH balance — PH's ledger is append-only, balance = SUM(delta), so it's a single number to read) — NOT a transfer/settlement, unless Sandon explicitly asks for the harder thing (which is then a fresh owner + counsel conversation).

Recommendation: v1 = intra-family chores → attributed credit (zero external money, zero strangers — just formalizes allowance/chores, and it needs no counsel gate because no minor touches real external money or an outside party). The neighborhood + real-external-credit layer is v2, and only through gates 2–4 above.

FAMILY KIDS CHORES — Docs | HiveJournal