콘텐츠로 이동
Life Cockpit Product Gate

5. Implementation Stack

5. Implementation Stack

섹션 제목: “5. Implementation Stack”

v0.5의 판단은 stack을 하나로 고르지 않고 역할별로 나누는 것이다.

첫 인터랙티브 probe에는 Phaser 4 + TypeScript + Vite를 유지한다. 다만 SvelteKit과 Rails 8도 후보군에 넣는다. SvelteKit은 DOM-heavy local-first cockpit이 필요해질 때의 중간 후보이고, Rails 8 line은 계정, 저장, 운영, 배포, admin, 장기 product loop가 필요해질 때의 기본 제품화 후보다.

Decision:
Use Phaser 4 + TypeScript + Vite for the first interactive Route Board prototype.
Consider SvelteKit when the prototype becomes a DOM-heavy local-first cockpit.
Use Rails 8 line when the product needs durable backend, accounts, admin, jobs, and deployment.


Boundary:
Keep the handbook in Astro/Starlight.
Keep domain contracts outside Phaser/Svelte scenes.
Do not add auth, cloud sync, analytics, or medical guidance in the first probe.

Stack Roles

섹션 제목: “Stack Roles”
Stack역할현재 판단
Astro Starlighthandbook, product gate, evidence유지
Phaser 4 + TypeScript + Vitefirst playable Route Board probe채택
SvelteKitDOM UI + local-first cockpit + Phaser island 후보조건부 후보
Rails 8 linedurable product shell, account/admin/data/jobs/deploy제품화 기본 후보

Phaser가 맞는 이유

섹션 제목: “Phaser가 맞는 이유”

Life Cockpit의 첫 검증은 “정보를 예쁘게 정리했는가”가 아니라 “지금 상태에서 착수 가능한 route를 몸으로 눌러볼 수 있는가”다. 이 질문에는 일반 CRUD UI보다 game loop가 더 잘 맞는다.

필요Phaser 4 + TS + Vite 적합성
energy state를 고르고 즉시 반응 보기scene, input, animation, state feedback이 빠름
boring task를 quest card로 바꾸기card, motion, drag/tap, reward feedback을 쉽게 실험
10분 session을 실제 흐름으로 느끼기timer, scene transition, progress, outcome state에 강함
route log를 죄책감 없이 남기기done/fork/retry/recover를 게임 결과처럼 표현 가능
짧은 prototype loopVite dev server와 HMR로 빠르게 수정 가능
객체 계약 고정TypeScript로 Task, Quest, Session, RouteLog shape를 먼저 고정 가능

공식 Phaser 자료 기준으로 Phaser 4는 WebGL/Canvas 기반 HTML5 game framework이고, JavaScript와 TypeScript 개발을 모두 지원한다. 2026-06-21 현재 공식 stable download는 Phaser v4.2.0 "Giedi"이며, 공식 template-vite-ts도 Phaser 4, Vite, TypeScript 조합을 제공한다.

Phaser의 위험

섹션 제목: “Phaser의 위험”

Phaser는 좋은 canvas/game engine이지, 일반 업무 앱 UI 프레임워크가 아니다. Life Cockpit을 전부 Phaser로 만들면 초반 속도는 빨라 보여도 접근성, 텍스트 편집, 설정, 데이터 검토, future backend 연동에서 비용이 생긴다.

위험대응
Phaser 4는 major release라 Phaser 3 자료와 차이가 날 수 있음공식 Phaser 4 docs/template 기준으로만 구현
canvas UI는 접근성, 텍스트 선택, form UX가 약함prototype route board에만 사용하고 설정/문서는 DOM UI로 분리
게임적 feedback이 guilt/streak loop로 변질될 수 있음reward는 pattern learning에만 쓰고 penalty/streak 금지
official template에 anonymous template usage log가 포함될 수 있음npm run dev-nolog/build-nolog 또는 log script 제거를 기본으로 둠
data layer가 engine 안에 갇힐 수 있음domain model과 route scoring은 pure TypeScript module로 분리
mobile/browser 성능 편차첫 slice는 desktop local prototype으로 제한

SvelteKit 판단

섹션 제목: “SvelteKit 판단”

SvelteKit은 Phaser보다 일반 앱 UI에 가깝고, Rails보다 client-side interaction 실험이 빠르다. 따라서 Life Cockpit이 canvas game loop보다 DOM dashboard, keyboard flow, local-first state, settings panel, route log review 쪽으로 빨리 커지면 SvelteKit이 좋은 중간 후보가 된다.

공식 SvelteKit 문서 기준으로 SvelteKit은 Svelte 기반 web app framework이며, SSR/CSR/SSG/SPA 등 여러 project type을 adapter와 설정으로 선택할 수 있다. 특히 SPA를 desktop app으로 감쌀 수 있고, separate backend도 가능하다. 이 점은 future local-first desktop cockpit 또는 Rails backend와의 분리에 잘 맞는다.

맞는 경우안 맞는 경우
Route Board 주변에 form, settings, log review가 많아진다첫 검증이 canvas interaction 하나로 충분하다
local-first cockpit을 Tauri/Electron 후보로 보고 싶다계정, 결제, admin, server-side data가 먼저 필요하다
Phaser를 island처럼 넣고 나머지는 DOM으로 만들고 싶다Rails product shell이 이미 필요한 단계다
TypeScript domain model을 UI와 가깝게 실험하고 싶다long-term persistence와 ops가 더 중요하다

SvelteKit을 쓰더라도 Phaser와 같은 원칙을 지킨다.

Domain model stays outside Svelte components.
Route scoring is pure TypeScript.
Phaser, if used, is an island under a SvelteKit shell.
No auth/cloud sync/analytics until a separate contract exists.

Rails 8 판단

섹션 제목: “Rails 8 판단”

Rails 8 line은 첫 playable probe에는 과하다. 하지만 제품화가 시작되면 가장 먼저 다시 봐야 한다. 이유는 Life Cockpit이 결국 Task, Quest, Session, RouteLog, 사용자 설정, 안전 boundary, export, admin/debug evidence 같은 durable data를 갖게 되기 때문이다.

공식 Rails 문서 기준으로 Rails 8.0 major features에는 Kamal 2, Thruster, Solid Cable, Solid Cache, Solid Queue, Propshaft, Authentication이 들어간다. 현재 Getting Started guide는 Rails 8.1.0 이상을 기준으로 새 앱 생성, database, MVC/REST, authentication, assets, testing, Kamal deploy까지 안내한다. 이 프로젝트의 governance 기본값도 새 일반 웹앱은 Rails 8 vanilla + Tailwind 4 + PostgreSQL이다.

맞는 경우안 맞는 경우
사용자 계정과 private route log가 필요하다아직 task 10개 seed로 local probe만 한다
admin/debug/evidence surface가 필요하다animation/game feel 자체가 검증 대상이다
background jobs, email, export, audit trail이 필요하다backend 없이 빠르게 장면을 만져봐야 한다
production deploy와 운영 단순성이 중요하다UI interaction이 너무 빨리 바뀐다

Rails를 쓰는 경우에도 Phaser/Svelte를 버리는 게 아니다. Rails가 durable product shell이 되고, Phaser Route Board 또는 SvelteKit-built front surface는 점진적으로 embed하거나 별도 package로 분리한다.

Rails owns:
User, Task, Quest, Session, RouteLog, audit/export/admin, deployment.


Phaser/Svelte owns:
Route Board interaction, session feel, local input feedback.


Shared:
TypeScript/Ruby data contract must be mirrored by tests or fixture snapshots.

채택 범위

섹션 제목: “채택 범위”
Layer선택
handbook/siteAstro Starlight 유지
first playable shellVite + TypeScript
first interactive surfacePhaser 4 scene
DOM-heavy local-first candidateSvelteKit
durable product shellRails 8 line, Tailwind 4, PostgreSQL
domain modelpure TypeScript module
persistencefirst slice는 local seed/in-memory 또는 local JSON
backendfirst slice 없음, productization 시 Rails
account/authfirst slice 없음, productization 시 Rails authentication path 검토
deployhandbook과 별도. 앱 deploy는 새 계약 전까지 하지 않음

첫 Prototype Shape

섹션 제목: “첫 Prototype Shape”

첫 화면은 Route Board 하나면 충분하다.

Left:
Task seed 10개


Top:
Energy state selector


Center:
Quest candidate card 최대 3개


Right:
10분 Session panel


Bottom:
Route Log rows

Phaser scene은 card movement, focus, timer, outcome feedback을 맡는다. 하지만 아래 로직은 scene 안에 넣지 않는다.

Task scoring
Quest compiling
Session outcome validation
RouteLog serialization
Safety/no-medical-claim guard

이 로직은 src/domain 같은 pure TypeScript module에 두고, Phaser는 그 결과를 그리는 adapter로만 쓴다.

Acceptance Scenario

섹션 제목: “Acceptance Scenario”
Feature: Stack role decision


  Scenario: Keep the first probe small while preserving productization path
    Given I have 10 seeded tasks
    And I choose one current energy state
    When the first playable prototype is built
    Then I should see no more than 3 quest cards
    And Phaser should own only the interactive Route Board feel
    And SvelteKit should remain a candidate for DOM-heavy local-first cockpit work
    And Rails 8 should remain the default durable product shell when accounts, persistence, or admin become necessary

Implementation Contract

섹션 제목: “Implementation Contract”
Stack:
Phase 1: Phaser 4 + TypeScript + Vite.
Phase 1.5 candidate: SvelteKit shell with Phaser island.
Phase 2 candidate: Rails 8 line product shell with durable data and ops.


Create path:
Use the official Phaser create-game/template path, then remove or disable template telemetry/logging before sensitive local use.
Do not create SvelteKit or Rails app until the Route Board evidence says the product needs that layer.


Prototype boundary:
No user account.
No cloud sync.
No analytics.
No notification loop.
No diagnosis, treatment, medication, or medical advice copy.


Architecture:
Phaser scene imports pure TypeScript domain functions.
Domain functions do not import Phaser.
RouteLog can be serialized without a canvas runtime.
SvelteKit components, if added, import the same domain functions.
Rails model contract, if added later, must be proven against the same fixture shape.


Done:
One local browser flow proves task -> quest -> session -> route log.
Build passes.
Manual local read-back confirms no more than 3 quest candidates and no medical claim.

지금 결론

섹션 제목: “지금 결론”

채택한다. 단, “Phaser app”이 아니라 “Phaser-powered probe”로 채택한다.

SvelteKit은 Route Board 주변의 DOM cockpit이 커질 때 고려한다. Rails 8 line은 제품화가 시작될 때 기본값으로 다시 본다. 지금 당장 Rails나 SvelteKit 앱을 만들지 않는 이유는 단순하다. 아직 검증해야 할 것은 backend가 아니라 route feel이다.

공식 문서 확인

섹션 제목: “공식 문서 확인”