WhyC Architecture v2 — PDD on Runtime¶

Status: 📋 Proposed (awaiting one more verification round before implementation) Authored: 2026-05-11 Authors: Two Weeks Team (Sejun Kim, ComBba) Target deadline: 2026-06-11 14:00 PT Track: Arize (Google Cloud Rapid Agent Hackathon)

This document captures the agreed-on-principle architecture for WhyC v2. The v1 architecture (runs/r-20260506T122526Z/specs/SPEC.md) and its v1 spec lock remain unchanged; v2 is a runtime-level redesign that ports PreviewForge's PDD methodology into the pipeline itself, not just into the design phase.

0. Why v2 — what v1 misses¶

WhyC v1 is a single-perspective LLM agent loop:

analyze(1 call) → go/no-go(rules) → develop(1 call) → deploy → judge(1 call) → improve

This is structurally identical to Bolt / Lovable / Replit Agent / v0.dev. No technical differentiation. Judges seeing v1 will categorize it as "another vibe-coding tool" and the Idea Quality (25 pts) collapses.

PDD's real value is in three signature patterns that v1 lacks:

v2 ports all three into the runtime pipeline. WhyC then is no longer "an AI that builds an app" — it's "an agent panel that converges on a build via structured adjudication," which is genuinely unprecedented in the gallery.

1. The 7-stage v2 pipeline¶

Each stage is documented with (a) multi-perspective generation, (b) validation, (c) re-validation, (d) failure / retry / learning, (e) context preservation, (f) GCP / Phoenix feature used.

Stage 0 — Pre-flight (NEW)¶

Stage 1 — Multi-Analyzer (REVISED)¶

Stage 2 — Go / No-Go + Vertex AI Eval¶

Stage 3 — Multi-Developer + I2 Dedup (BIGGEST CHANGE)¶

Stage 4 — Deploy (real, not v1 stub)¶

Stage 5 — 5-Critic Judge Panel (REVISED)¶

Stage 6 — Phoenix MCP Introspection (EXTENDED)¶

Stage 7 — Self-Improve + BigQuery Learning (NEW LEARNING LAYER)¶

2. Cross-cutting concerns¶

2.1 Validation matrix¶

2.2 Retry budget per stage¶

analyze:         3 advocate × 2 retries  =  6 LLM calls max
go/no-go:        1 eval × 1 retry        =  2 LLM calls max
develop:         5 advocate × 2 retries  = 10 LLM calls max
deploy:          Cloud Build × 2 retries =  build attempts
judge:           5 critic × 1 retry      = 10 LLM calls max
introspect:      MCP × 1 retry           =  2 MCP calls max
self-improve:    BigQuery × 1 retry      =  2 BQ queries max
─────────────────────────────────────────────────────────
worst-case per iter: ~30 LLM calls + 2 builds + 2 MCP + 1 BQ
typical per iter (no retries): ~14 LLM calls + 1 build + 1 MCP + 1 BQ

2.3 Three-layer context preservation¶

2.4 Learning loop (BigQuery, kicks in N ≥ 10 runs)¶

At Stage 1 entry:
  prior_specs ← BQ.SELECT ProductSpec WHERE input_id_similarity(NEW_INPUT) > 0.6 LIMIT 5
  include as exemplars in analyzer prompt

At Stage 3 entry:
  winning_advocate_history ← BQ.SELECT advocate_id, COUNT(*) WHERE outcome='converged' GROUP BY advocate_id
  weight the multi-developer dispatch (still 5 parallel, but the high-win advocate gets higher temperature)

At Stage 7 entry:
  regen_history ← BQ.SELECT regen_flow, AVG(spec_fit_delta) WHERE weakest_flow = ?
  inform `decideNext` — if regenerating flow X has historically helped, do it

This is what makes the demo video say "the agent gets smarter run by run" — not just iter by iter, but across companies. Genuinely demonstrable.

3. GCP + Phoenix native feature inventory¶

9 GCP services + 5 Phoenix features = unprecedented integration depth for a 2-person hackathon team.

4. Hackathon scoring axis impact¶

Reasoning: - Tech Implementation lift comes from Agent Builder sub-agents (rules-mandated), Vertex AI Eval, BigQuery learning, Phoenix 5-feature integration. Each is independently grade-able. - Design lift comes from 5 developer advocates → I2 dedup → judge cross-pick. The final preview shipped to the wall is by construction the consensus of 5 design lenses. - Potential Impact lift comes from the learning loop: "100 runs later, the agent is empirically better at this category of company." Demoable from BigQuery. - Quality of Idea lift comes from PDD-on-Runtime being structurally unprecedented in the hackathon gallery. Judges have not seen 13 sub-agents adjudicating per-run in any prior submission.

5. Cost projection¶

Per converged run (3 iter average):
  Stage 1: 3 analyzers (Flash) + 1 synth (Pro)       ~$0.15
  Stage 2: 1 eval call (Flash)                        ~$0.02
  Stage 3: 5 developers (Pro) × 3 iter                ~$1.50
  Stage 4: Cloud Build minutes                        ~$0.05
  Stage 5: 5 critics (Pro) × 3 iter                   ~$1.20
  Stage 6: Phoenix MCP (free under 50k traces/mo)     ~$0.00
  Stage 7: BigQuery (free tier)                       ~$0.00
  Cloud Run + SQL fixed                                ~$0.20
  ──────────────────────────────────────────────────────────
  TOTAL per run                                       ~$3.12

12 demo runs:                                         ~$37
Buffer for retries + experiments:                     ~$25
TOTAL:                                                ~$62 of $100 credit (62 %)

Safety margin: $38 (38 %) remaining for: video re-renders, additional dataset experiments, demo-day live invocation.

6. Timeline (D-30 → D-0)¶

7. Risk register¶

8. Demo video (3 min, receipts tone)¶

0:00 – 0:15  Hook
             "VC raised. Hiring posted. Product page empty."

0:15 – 0:45  Input
             User pastes a public Y Combinator company URL on whyc.example

0:45 – 1:30  Live multi-agent progress
             [Stage 1] 3 analyzers (split screen) → 1 spec via synthesis
             [Stage 3] 5 developers in parallel → I2 dedup → 1 winner
             [Stage 5] 5 critics scoring panel → spec_fit 0.71
             [Stage 6] Phoenix dashboard, MCP query in progress

1:30 – 2:15  Self-improvement loop accelerated
             iter 3 → spec_fit 0.84
             iter 7 → spec_fit 0.96, converged
             Phoenix experiment comparison: "+12 % vs prior converged runs"

2:15 – 2:45  Receipts grid
             12 real YC companies × days_since_DD vs WhyC_ship_time

2:45 – 3:00  Closing
             "Same pipeline. Any founder, any idea, 1 day."
             [Apache-2.0 badge] [github.com/Two-Weeks-Team/WhyC]

9. Operational notes (post-credit-application)¶

• Google Cloud account: app.2weeks@gmail.com (existing, already linked to Devpost via the credit application)
• Billing account: the one named "크레딧" (created specifically to redeem this hackathon's $100 coupon)
• Redeem path: console.cloud.google.com/billing/redeem — apply the coupon to the "크레딧" billing account only
• Approval window: 1–5 business days; coupon arrives from Partner-developer-marketing@google.com
• Hard redeem deadline: 2026-06-04 (no extension)
• Project to be linked: whyc-prod (to be created — deploy/README.md §1 documents the steps)

10. What's NOT in v2 (deferred)¶

These were considered and explicitly held back because they don't move the scoring needle for the hackathon window:

• Multi-language analyzer (Korean / Japanese / etc.) — English-only for v1 dataset
• Real-time progressive deploy (deploy mid-iteration as flows complete) — saved for v3
• Cross-company shared learning beyond batch-level — needs N ≥ 50 runs
• Public submission form (anyone can paste a URL) — H1 locked this closed
• Mobile app — H1 locked web-only

11. Verification protocol before implementation¶

This document is a proposal, not a commitment. Before any code is written for v2, the team will:

1. Walk through this document together
2. Confirm each of the 13 sub-agent roles is sensible
3. Confirm the cost projection holds against current Gemini pricing
4. Confirm the Agent Builder console actually supports the sub-agent registration pattern we describe
5. Confirm BigQuery free tier covers the per-run insert volume

After verification, an architecture-v2-locked.md is created with the final agreed shape, and implementation work begins against that.

12. Changelog¶