HS.
← Selected work

Case 01 / Design

FamilyPal

How could a family coordination problem become a clearly defined, testable product?

Independent Product Work

FamilyPal began with an everyday problem: family information, responsibilities, appointments, and plans become fragmented across people and places.

The goal was not simply to build an app.

The challenge was turning an ambiguous human problem into explicit requirements, boundaries, tests, and evidence—without allowing implementation momentum to quietly redefine the product.

My role
Product direction · Requirements · Decision authority · Acceptance
AI / Tools
Bumblebee — investigate & challenge
Codex — implement & test
Current state
Partially verified
Production change not authorized

01 / From problem to system

Family problems rarely arrive as requirements.

“We forgot.”

“I thought you were handling it.”

“Where is that information?”

“Who is responsible?”

Family memory

Keep important information accessible.

Family operations

Coordinate responsibilities and recurring work.

Family planning

Make upcoming decisions and commitments visible.

The first design decision was therefore not a feature. It was to establish a controlled definition of what problem the product was supposed to solve.

02 / The decision that mattered

A working system can still be the wrong system.

Builds could pass. Routes could respond. Authentication could work. Tests could complete.

None of those facts independently proved that the original requirement had been satisfied.

  1. Requirement
  2. Implementation
  3. Test
  4. Evidence
  5. Human acceptance

The latest code could not silently become the specification. And technical success could not authorize its own production release.

03 / Human × AI division of work

Execution capacity and decision authority were deliberately separated.

Hongmin / Product authority

  • Frame the problem
  • Set requirements and boundaries
  • Define acceptance criteria
  • Evaluate material risk
  • Accept / reject / revise
  • Authorize production changes

Bumblebee / Investigate & challenge

  • Structure requirements
  • Challenge assumptions
  • Compare alternatives
  • Review evidence
  • Identify gaps and contradictions

Codex / Implement & verify

  • Inspect the repository
  • Implement bounded changes
  • Run tests
  • Produce logs and technical evidence

AI could investigate and execute.It could not inherit product authority.

04 / A real stress test

V24 authentication tested the operating model.

Instead of treating a successful implementation as permission to change production, authentication work was isolated and tested separately.

Verified

  • PASSUnknown-email enumeration protection
  • PASSEmail delivery
  • PASSAuthentication token stored as a hash
  • PASSExposed test token invalidated
  • PASSGET confirmation did not consume the token
  • PASSPOST consumption and session creation verified
  • PASSMember/session preservation through isolated migration testing

These results established specific technical facts.They did not establish that V24 as a whole was production-ready.

That distinction mattered more than the number of PASS results.

05 / What went wrong

Failure changed the operating method.

Human operating error

Multiple PowerShell windows became difficult to distinguish.

Change: Terminal roles and environments required clearer identification.

Test credential exposure

A raw authentication token became exposed during testing. It was not dismissed because it occurred in a test environment.

Change: Invalidate the token and tighten the test procedure.

False confidence from technical success

A successful command or exit code could show that a process completed. It could not prove that the intended security behavior, user experience, or requirement had been satisfied.

Change: Distinguish execution evidence from semantic acceptance evidence.

06 / The controls

Those failures changed how the project operated.

Controlled requirements
The SRS—not the latest implementation—remains the requirements authority.
Protected production boundary
Test success does not authorize deployment.
Isolated testing
Material authentication changes can be tested without silently changing production.
Evidence states
PASS / FAIL / UNKNOWN
Human UAT
Where acceptance depends on real human interaction, synthetic execution does not substitute for authorized user testing.
Human release authority
AI analysis and automated tests cannot independently authorize production changes.

07 / Current status

Specific evidence. Bounded conclusion.

V23Controlled production baseline
V24Authentication work tested in isolation

Not authorized for production

Authentication work has produced meaningful evidence in an isolated environment. But V24 has not been authorized for production.

Partially verifiedProduction not authorized

Leaving unresolved work unresolved is part of the control system.

08 / What this case demonstrates

Turning ambiguity into a controlled, testable system.

FamilyPal is not presented as evidence that I am a software engineer. It demonstrates something more relevant to how I work.

The project required me to connect:

Human problem → requirements → implementation → testing → evidence → decision

Build → Test → FixDefine → Build → Attack → Evidence → Decide

AI increased how much I could investigate, build, and test. It did not change who had to decide what the evidence meant.

Selected receipts

Evidence retained. Not publicly displayed.

01

Controlled SRS

Requirements authority, scope, and acceptance boundaries.

Evidence retained / not publicly displayed
02

V24 authentication test

Isolated authentication and migration evidence.

Evidence retained / not publicly displayed
03

Evidence record

PASS / FAIL / UNKNOWN decisions and unresolved boundaries.

Evidence retained / not publicly displayed
04

Production boundary

V23 controlled baseline. V24 production not authorized.

Evidence retained / not publicly displayed