diff --git a/.github/workflows/astro.yml b/.github/workflows/astro.yml
index 5da8748..fcdd4e9 100644
--- a/.github/workflows/astro.yml
+++ b/.github/workflows/astro.yml
@@ -8,8 +8,15 @@ on:
release:
types: [published]
- # Allows you to run this workflow manually from the Actions tab
+ # Allows you to run this workflow manually from the Actions tab.
+ # 수동 배포는 항상 릴리즈 태그를 입력해야 합니다.
+ # "Use workflow from"은 반드시 main(이 workflow가 있는 브랜치)을 선택하세요.
workflow_dispatch:
+ inputs:
+ tag:
+ description: "배포할 릴리즈 태그 (예: v2.15.1)"
+ required: true
+ type: string
# Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages
permissions:
@@ -34,6 +41,12 @@ jobs:
steps:
- name: Checkout
uses: actions/checkout@v7
+ with:
+ # release 이벤트에서는 inputs.tag가 비어 있어 github.ref(릴리즈 태그)를 사용하고,
+ # 수동 실행에서는 입력한 태그만 체크아웃합니다. (브랜치 이름은 거부됩니다)
+ ref: ${{ inputs.tag && format('refs/tags/{0}', inputs.tag) || github.ref }}
+ - name: Show deployed ref
+ run: echo "Deploying ${{ inputs.tag || github.ref_name }}" >> $GITHUB_STEP_SUMMARY
- name: Detect package manager
id: detect-package-manager
run: |
diff --git a/src/content/faq/index.mdx b/src/content/faq/index.mdx
index a66f486..ef6b95b 100644
--- a/src/content/faq/index.mdx
+++ b/src/content/faq/index.mdx
@@ -42,7 +42,7 @@ REPL Works는 **인간 엔지니어와 AI가 장기간 프로젝트를 지속
| 비교 항목 | 일반 AI Agent (Action Focus) | REPL Works (Memory & Workflow) |
| :----------------- | :---------------------------------- | :------------------------------------------- |
| **핵심 목적** | 일회성 작업 및 코드 자동 생성 | 프로젝트 수명 주기 지속성 및 의도 유지 |
-| **기억 저장 위치** | 일시적 대화 세션, Vector DB, 런타임 | Git 저장소 + Markdown 6대 표준 문서 |
+| **기억 저장 위치** | 일시적 대화 세션, Vector DB, 런타임 | Git 저장소 + Markdown 6+1종 표준 문서 |
| **모델 의존성** | 높음 (특정 LLM 맥락에 강하게 의존) | 매우 낮음 (문서 기반 모델 독립성 확보) |
| **모델 변경 시** | 프롬프트 재설정 및 세션 재구성 필요 | 마크다운 명세서 읽기로 즉각 복원 가능 |
| **핵심 질문** | _"지금 어떤 코드를 작성할까?"_ | _"왜 이 프로덕트를 만들고 어떻게 유지할까?"_ |
@@ -97,9 +97,9 @@ REPL Works 파이프라인에서는:
---
-### Q8. 왜 6대 표준 문서로 역할을 분리했나요?
+### Q8. 왜 6종 표준 문서로 역할을 분리했나요?
-단일 거대 문서나 무질서한 파편화 문서는 AI와 사람 모두에게 혼란을 줍니다. REPL Works는 수많은 개발 문서를 AI가 가장 잘 이해하는 **6대 표준 명세 헌법**으로 정량화했습니다:
+단일 거대 문서나 무질서한 파편화 문서는 AI와 사람 모두에게 혼란을 줍니다. REPL Works는 수많은 개발 문서를 AI가 가장 잘 이해하는 **6+1종 표준 명세 헌법**으로 정량화했습니다:
diff --git a/src/content/showcase/ai-issue.mdx b/src/content/showcase/ai-issue.mdx
index ced2aaa..2ea3837 100644
--- a/src/content/showcase/ai-issue.mdx
+++ b/src/content/showcase/ai-issue.mdx
@@ -1,7 +1,7 @@
---
title: 'AI Issue Publisher 쇼케이스'
-version: 'v2'
-description: '대화 맥락을 코딩형 AI가 즉시 수용할 수 있는 수락 조건 명세 Issue로 변환해 주는 호환 도구 프로젝트'
+version: 'v3'
+description: '`ai-issue`는 AI와 나눈 대화에서 나온 작업 항목을 GitHub Issue로 발행하는 CLI 도구입니다.'
publishedAt: '2026-10-02T00:00:00Z'
---
@@ -13,58 +13,90 @@ import WorkflowFlow from '../../components/WorkflowFlow.astro';
## 1. 개요 (Overview)
-`ai-issue`는 REPL Works 프레임워크의 첫 번째 호환 CLI 도구입니다. 막연한 대화나 아이디어를 코딩형 AI가 추측 없이 실행할 수 있는 표준 구조의 GitHub Issue로 자동 작성해 줍니다.
+`ai-issue`는 AI와 나눈 대화에서 나온 작업 항목을 GitHub Issue로 발행하는 CLI 도구입니다. 채팅창 안에서 사라지기 쉬운 가치 있는 작업이 프로젝트 백로그에 남도록 하는 것이 목적이며, REPL Works 방식으로 개발한 첫 번째 호환 도구입니다.
-
+
----
+```bash
+brew install replworks/tap/ai-issue
+```
+
+Linux는 [APT 저장소](https://apt.repl.net)에서 설치합니다. 소스는 [GitHub](https://github.com/replworks/ai-issue)에 공개되어 있고 MIT 라이선스입니다.
## 2. 사용된 표준 문서 (Documents Used)
-
+문서는 모두 저장소에 있습니다. 사람을 위한 문서와 AI를 위한 문서가 디렉터리로 나뉘어 있고, AI는 `docs/` 아래 문서를 요구사항으로 쓰지 않습니다.
----
+- 사람을 위한 문서: [IDEAS.md](https://github.com/replworks/ai-issue/blob/main/.replworks/docs/IDEAS.md), [PITCHING_SCRIPT.md](https://github.com/replworks/ai-issue/blob/main/.replworks/docs/PITCHING_SCRIPT.md)
+- AI를 위한 문서: [PRODUCT_SPEC.md](https://github.com/replworks/ai-issue/blob/main/.replworks/PRODUCT_SPEC.md), [TECH_STACK.md](https://github.com/replworks/ai-issue/blob/main/.replworks/TECH_STACK.md), [ARCHITECTURE.md](https://github.com/replworks/ai-issue/blob/main/.replworks/ARCHITECTURE.md), [TASKS.md](https://github.com/replworks/ai-issue/blob/main/.replworks/TASKS.md)
+- 공통 규칙: [AGENTS.md](https://github.com/replworks/ai-issue/blob/main/AGENTS.md)
-## Workflow Usage
+## 3. 적용 워크플로 (Workflow Usage)
-`ai-issue` 도구 개발 시 다음과 같은 REPL Works 워크플로를 적용했습니다:
+`ai-issue`를 개발할 때 다음 순서를 적용했습니다.
-
+```text
+대화형 AI (이슈 구조화 가이드라인 설계)
+ ↓
+PRODUCT_SPEC.md & ARCHITECTURE.md (CLI 구조 수립)
+ ↓
+코딩형 AI (Homebrew / APT로 설치할 수 있는 CLI 구현)
+ ↓
+Human Review (로컬 터미널 검증 및 Release)
+```
----
+### 기능 하나가 바뀌는 과정
+
+기능 요청 [#33](https://github.com/replworks/ai-issue/issues/33)은 개인 액세스 토큰(PAT) 대신 GitHub App의 Device Flow 인증을 쓰자는 것이었습니다. 이 요청은 PR [#38](https://github.com/replworks/ai-issue/pull/38)이 되었고, [커밋 하나](https://github.com/replworks/ai-issue/commit/c0a1243691c43c8bc548e6e123111544de49b966)에 문서와 구현과 테스트가 함께 들어갔습니다.
+
+- `PRODUCT_SPEC.md`에 요구사항 `FR-011`(Device Flow 로그인 지원)이 추가되었습니다.
+- `ARCHITECTURE.md`에 인증을 맡는 `Authentication Resolution` 모듈이 추가되었고, 이슈 생성이나 저장소 선택은 이 모듈의 책임이 아니라고 명시되었습니다.
+- `TECH_STACK.md`에 토큰을 제한된 파일 권한으로 로컬에 저장해야 한다는 규칙이 추가되었고, 구현에서는 토큰 파일을 `0o600` 권한으로 씁니다.
+- `TASKS.md`에 `Authentication` 작업과 수락 조건이 추가되었습니다.
+
+```text
+ ARCHITECTURE.md | 19 ++++++++
+ FRAMEWORK.md | 2 +
+ PRODUCT_SPEC.md | 16 +++++++
+ TASKS.md | 14 ++++++
+ internal/adapter/github/client.go | 124 ++++++++++++++++++++++++++++++++++++++++++++++++---
+ internal/cli/login.go | 93 ++++++++++++++++++++++++++++++++++++++
+ internal/config/config.go | 56 +++++++++++++++++++++++
+ ... (테스트 파일 포함 총 13개 파일, +500 −23)
+```
+
+이 커밋은 문서 구조가 현재의 `.replworks/` 방식으로 바뀌기 전의 것이어서, 문서가 저장소 루트에 있고 `TECH_STACK.md`가 `FRAMEWORK.md`라는 이름이었습니다. 역할은 같습니다. 단계별 설명은 [워크플로우](/workflow)에서 이 커밋을 예시로 따라갑니다.
-## Tools Used
+## 4. 사용 기술 (Tools Used)
-- **Go / Rust CLI**: 초경량 교차 플랫폼 CLI 바이너리 런타임
-- **GitHub CLI (gh)**: GitHub API 이슈 자동 발행 액션
+- **Go**: 단일 바이너리로 배포하는 교차 플랫폼 CLI 런타임
+- **GitHub App (Device Flow)**: 개인 액세스 토큰 없이 여러 조직에서 로그인하는 인증 방식
- **REPL Works Issue Template**: 수락 조건 표준 템플릿
+- **golangci-lint, GoReleaser, GitHub Actions**: 정적 검사, 릴리즈 패키징, 자동 검증과 배포
----
+## 5. 배포와 운영 (Release & Operations)
-## 5. 학습된 레슨 (Lessons Learned)
+사람이 배포 명령을 직접 실행하지 않습니다. 변경은 PR에서 자동 검증을 거치고, 릴리즈는 태그 하나로 시작됩니다. 이 흐름은 GitHub Actions workflow로 정의되어 있으며 [Homebrew 저장소](https://brew.repl.net)와 [APT 저장소](https://apt.repl.net)에서 직접 볼 수 있습니다.
-
+```text
+PR → CI 검증 → 머지 → 태그(v*) → 릴리즈 workflow → Homebrew · apt 배포
+```
+
+**검증.** [ci.yml](https://github.com/replworks/ai-issue/blob/main/.github/workflows/ci.yml)은 main과 develop에 push할 때와 모든 PR에서 실행됩니다. Go 버전은 `go.mod`에서 읽고, `make check`와 golangci-lint를 통과해야 합니다.
+
+**릴리즈.** [release.yml](https://github.com/replworks/ai-issue/blob/main/.github/workflows/release.yml)은 `v*` 태그를 push하면 시작합니다. 수동으로 실행할 수도 있고, 이때는 태그를 입력으로 받습니다. 먼저 gofmt, `go vet`, `go test`를 다시 확인한 뒤 GoReleaser가 GitHub 릴리즈를 만들고 [Homebrew](https://brew.repl.net) 배포를 처리합니다. 마지막 단계에서 apt 저장소(`replworks/apt`)에 릴리즈가 나왔다고 알리면, [APT 저장소](https://apt.repl.net)의 갱신은 그쪽에서 이어집니다.
+
+**상태와 복구.** `ai-issue`는 사용자 데이터를 저장하지 않는 CLI라서 백업할 상태가 없습니다. 소스는 Git에 있고, 배포 산출물은 태그가 있으면 같은 소스로 다시 빌드할 수 있습니다.
+
+## 6. 학습된 레슨 (Lessons Learned)
+
+모호한 지시는 에이전트의 환각을 유발합니다. 수락 기준(Acceptance Criteria)이 명시된 이슈일수록 구현이 정밀해집니다.
+
+요구사항 하나는 문서 여러 개를 바꿉니다. 인증 방식을 바꾸는 한 번의 변경이 제품 정의, 구조, 기술 규칙, 작업 목록을 모두 건드렸고, 이것이 한 커밋에 남아 있어 나중에도 변경의 이유를 추적할 수 있습니다.
+
+AI는 문서에 없는 일은 하지 않습니다. 구현을 마친 작업을 `TASKS.md`에서 완료로 체크하는 단계가 `AGENTS.md`에 없어서, 구현 커밋에서 체크가 누락되었습니다. 나중에 발견해 AI에게 체크를 지시해 고쳤고, 완료 체크를 `AGENTS.md`의 작업 절차에 추가했습니다. 문제를 고치는 곳은 프롬프트가 아니라 문서입니다.
+
+CLI 도구도 REPL Works 문서를 따를 때 장기 유지가 쉬워집니다.
+REPL Works 웹사이트는 이 프레임워크의 공식 웹사이트이자, REPL Works 방법론과 문서를 실제로 적용한 첫 번째 도그푸딩 참조 프로덕트입니다.
----
+
+
+소스는 [GitHub](https://github.com/replworks/replworks.github.io)에 공개되어 있고 MIT 라이선스입니다.
## 2. 사용된 표준 문서 (Documents Used)
-본 프로젝트는 .replworks 디렉터리 내에 6대 표준 문서를 상시 유지 관리합니다.
-
-
+`.replworks/` 디렉터리에 표준 문서 6종을 유지하고, 저장소 루트의 `AGENTS.md`가 공통 규칙을 정합니다. 문서 전체는 [저장소](https://github.com/replworks/replworks.github.io/tree/main/.replworks)에서 볼 수 있습니다.
----
+- 사람을 위한 문서: `IDEAS.md`, `PITCHING_SCRIPT.md`
+- AI를 위한 문서: `PRODUCT_SPEC.md`, `TECH_STACK.md`, `ARCHITECTURE.md`, `TASKS.md`
+- 공통 규칙: `AGENTS.md` (저장소 루트)
-## Workflow Usage
+이 사이트는 문서를 소개하는 데 그치지 않고, 같은 저장소의 원본 파일을 그대로 보여줍니다. 표준 문서 페이지의 `AGENTS.md`와 프롬프트 페이지의 프롬프트는 `templates/`의 원본 파일을 빌드할 때 읽어 온 것이고, 복사한 사본이 아닙니다.
-웹사이트 구축 과정은 아래 3단계 워크플로 파이프라인을 100% 준수하여 진행되었습니다:
+## 3. 적용 워크플로 (Workflow Usage)
-
+웹사이트도 다음 순서로 개발합니다.
----
+```text
+대화형 AI (제품 요구사항과 아키텍처 토론)
+ ↓
+REPL Works 문서 (Git 기반 마크다운으로 자산화)
+ ↓
+코딩형 AI (1-Prompt = 1-Task = 1-Commit으로 구현)
+ ↓
+Human Review (검증 결과를 확인하고 Merge)
+```
+
+이 흐름은 실제로 이렇게 돌았습니다. v2 출시 직전의 콘텐츠 리뷰가 대표적인 예입니다. `TASKS.md`의 T601부터 T606까지 여섯 개 태스크(워크플로, 프롬프트, 문서, 도구, 쇼케이스, FAQ 리뷰)를 각각 Issue 하나로 만들고(#38~#42, #48), Issue마다 PR 하나로 구현했습니다(#43~#47, #49). 태스크 6개, Issue 6개, PR 6개가 일대일로 대응합니다.
+
+이 워크플로는 한 번 정해서 끝난 것이 아니라 사이트를 개발하면서 고쳐 왔습니다. 대표적인 변화는 다음과 같습니다.
-## Tools Used
+- 규칙(`AGENTS.md`)은 이 저장소에서 먼저 바꿔 써 보고, 확정되면 사이트에 보이는 원본(`templates/documents/AGENTS.md`)에 반영합니다.
+- 표준 문서와 프롬프트의 원본이 별도 저장소에 있던 것을 이 저장소의 `templates/`로 모았습니다. 이제 바뀌는 곳만 고치면 사이트가 따라옵니다.
+- README에 있던 방법론 설명을 사이트로 일원화했습니다. 같은 내용이 두 곳에 있어서 갱신 순서가 서로 어긋났기 때문입니다. README는 개발과 운영에 필요한 내용만 남겼습니다.
+- 두 AI 역할의 이름을 사이트 전체에서 대화형 AI와 코딩형 AI로 통일했습니다. 처음에는 Discussion AI와 Execution AI라고 불렀습니다.
-- **Vite & Astro 6+**: 정적 사이트 컴파일 엔진
-- **Pagefind**: 서버 없는 클라이언트 전용 초고속 정적 색인 검색 엔진
+## 4. 사용 기술 (Tools Used)
+
+- **Astro 7, Vite 8**: 정적 사이트 컴파일 엔진
+- **Tailwind CSS 4, MDX, Expressive Code**: 스타일, 콘텐츠 작성, 코드 블록 표시
+- **Pagefind**: 서버 없이 동작하는 정적 검색
+- **Vitest, Playwright**: 단위 테스트와 E2E 테스트
+- **ESLint, Prettier, `astro check`**: 정적 검사
+- **`astro-broken-links-checker`**: 빌드 중 깨진 내부 링크 검사
+- **GitHub Actions, GitHub Pages**: 검증, 빌드, 배포
- **ai-issue**: GitHub Issue 자동화 CLI 도구
----
+## 5. 배포와 운영 (Release & Operations)
-## 5. 학습된 레슨 (Lessons Learned)
+배포는 GitHub Pages로 합니다. 서버가 없고, 사이트는 빌드 결과물이며 원본은 모두 Git에 있습니다.
-
+**배포.** 이 사이트는 GitHub Release를 발행해야만 배포됩니다. 커밋을 올리거나 머지하는 것만으로는 배포되지 않고, 세상에 내보낼 시점은 사람이 정합니다. 그래서 릴리즈를 무겁게 만들지 않고 자주 발행합니다. 10월 3일 하루에만 v2.10.2부터 v2.11.2까지 릴리즈 11개를 발행했습니다. [astro.yml](https://github.com/replworks/replworks.github.io/blob/main/.github/workflows/astro.yml)은 Release를 발행하면 시작합니다. Actions에서 수동으로 실행할 수도 있는데, 이때는 배포할 릴리즈 태그를 직접 입력해야 하고 그 태그의 소스를 빌드해 배포합니다. 수동 배포도 태그가 있어야 합니다. Node 24로 `npm ci`를 실행하고, GitHub Pages 설정의 주소로 `astro build`를 실행해 `dist/`를 올립니다. 배포는 동시에 하나만 진행되고, 진행 중인 배포는 취소하지 않습니다.
+
+**검증.** 검증은 두 곳에서 합니다. 먼저 변경을 올리기 전에 로컬에서 `npm run check`로 lint, 포맷, 타입, 테스트(Vitest와 Playwright), 빌드를 한 번에 확인합니다. 그다음 `main`이나 `develop`에 push하거나 PR을 올리면 GitHub Actions의 `ci.yml`이 lint, 포맷 검사, 빌드를 실행합니다. 빌드 단계에서는 깨진 내부 링크가 하나라도 있으면 실패하므로 로컬과 CI 양쪽에서 걸립니다. 테스트는 CI에서 돌리지 않고 로컬 `npm run check`에서만 돌립니다. `src/site-invariants.test.ts`는 사이트가 지켜야 할 불변 조건을 확인하는 테스트입니다. 예를 들어 `AGENTS.md` 문서 페이지가 `templates/documents/AGENTS.md`를 직접 참조하는지 검사합니다. 코드를 한 줄씩 읽어 검토하지 않고, 이 검사들을 통과하는지로 판단합니다.
+
+**검증과 배포의 관계.** `ci.yml`은 push와 PR에서, `astro.yml`은 Release 발행이나 태그를 입력한 수동 실행에서 시작하는 별개의 workflow입니다. 그래서 CI가 실패해도 배포 workflow가 자동으로 막히지는 않고, Release를 발행하면 배포됩니다. `astro.yml`은 빌드만 하므로 테스트를 거치지 않습니다. CI 결과를 보고 Release를 발행할지는 사람이 정합니다. 자동 게이트로 막는 대신 Release를 발행하는 사람의 판단에 맡기는 것이 이 사이트의 운영 방식입니다.
+
+**상태와 복구.** 서버나 데이터베이스가 없어서 백업할 상태가 없습니다. 소스는 Git에 있고, 사이트는 같은 소스에서 다시 빌드해 배포할 수 있습니다.
+
+## 6. 학습된 레슨 (Lessons Learned)
+
+Content First: 구현 코드는 언제든 바뀌지만, 잘 정제된 문서는 프로젝트의 기억으로 남습니다.
+
+Discussion != Execution: 토론하는 AI와 구현하는 AI를 나누면 구현 단계는 확정된 문서가 정한 범위 안에서만 움직입니다.
+
+Git Is Truth: 대화 세션은 사라지지만 Git 커밋과 마크다운 문서는 어떤 AI 모델이든 이어받을 수 있게 합니다.
+
+Single Source of Truth: 원본은 한 곳에 둡니다. 같은 내용이 두 곳에 있으면 한쪽은 반드시 낡습니다. 방법론 설명이 README와 사이트에 따로 있을 때 갱신 순서가 서로 달랐고, 표준 문서와 프롬프트가 별도 저장소에 있을 때는 변경이 번거로웠습니다. 원본을 `templates/`에 모으고 사이트가 그것을 읽게 하자 바뀌는 곳만 고치면 되었습니다.
@@ -63,7 +63,7 @@ WIFI Note 프로젝트 개발 시 적용된 REPL Works 표준 파이프라인입
## Tools Used
- **Frontend / Fullstack**: React / Modern Web Framework
-- **Project Memory Management**: REPL Works 6대 표준 문서 & Git Repository
+- **Project Memory Management**: REPL Works 6+1종 표준 문서 & Git Repository
- **AI Automation**: 대화형 AI & 코딩형 AI agent pipeline
---
diff --git a/src/data/showcase.ts b/src/data/showcase.ts
index bc04fa6..396cadc 100644
--- a/src/data/showcase.ts
+++ b/src/data/showcase.ts
@@ -16,7 +16,7 @@ export const showcaseProjects: ShowcaseProject[] = [
slug: 'repl-works-website',
name: 'REPL Works 웹사이트',
description:
- 'REPL Works 방법론과 6대 표준 문서를 스스로에게 최초로 적용한 도그푸딩(Dogfooding) 참조 프로덕트',
+ 'REPL Works 방법론과 6+1종 표준 문서를 스스로에게 최초로 적용한 도그푸딩(Dogfooding) 참조 프로덕트',
tags: ['Website', 'Dogfooding'],
lesson:
'Content First: 구현 코드는 언제든 바뀌지만, 잘 정제된 문서는 프로젝트 기억으로 영구 보존됩니다.',
@@ -26,17 +26,31 @@ export const showcaseProjects: ShowcaseProject[] = [
featured: true,
order: 1,
},
+ {
+ slug: 'wifi-note',
+ name: '와이파이 노트 (WIFI Note)',
+ description:
+ '구조화된 프로젝트 기억을 통한 제품 개발 및 비즈니스 로직 연산을 증명하는 REPL Works 호환 웹 애플리케이션',
+ tags: ['Commercial', 'Web App'],
+ lesson:
+ '제품 의도 유지: 개발 진행 상황에서 코드가 늘어나더라도 왜 이 제품을 만드는지에 대한 핵심 의도가 훼손되지 않습니다.',
+ detailUrl: '/showcase/wifi-note',
+ website: 'https://wifinote.net',
+ featured: true,
+ order: 2,
+ },
{
slug: 'ai-issue',
name: 'AI Issue Publisher',
description:
- '대화 맥락을 코딩형 AI가 즉시 수용할 수 있는 수락 조건 명세 Issue로 변환해 주는 호환 도구 프로젝트',
+ 'AI와 나눈 대화에서 나온 작업 항목을 GitHub Issue로 발행하는 CLI 도구입니다.',
tags: ['Tooling', 'CLI'],
- lesson: '모호한 지시는 에이전트의 환각을 유발합니다.',
+ lesson:
+ '모호한 지시는 에이전트의 환각을 유발합니다. 수락 기준(Acceptance Criteria)이 명시된 이슈일수록 구현이 정밀해집니다.',
detailUrl: '/showcase/ai-issue',
github: 'https://github.com/replworks/ai-issue',
featured: true,
- order: 2,
+ order: 3,
},
{
slug: 'claytube',
@@ -50,19 +64,6 @@ export const showcaseProjects: ShowcaseProject[] = [
website: 'https://www.palgle.com/claytube/',
github: 'https://github.com/eternops/claytube',
featured: true,
- order: 3,
- },
- {
- slug: 'wifi-note',
- name: '와이파이 노트 (WIFI Note)',
- description:
- '구조화된 프로젝트 기억을 통한 제품 개발 및 비즈니스 로직 연산을 증명하는 REPL Works 호환 웹 애플리케이션',
- tags: ['Commercial', 'Web App'],
- lesson:
- '제품 의도 유지: 개발 진행 상황에서 코드가 늘어나더라도 왜 이 제품을 만드는지에 대한 핵심 의도가 훼손되지 않습니다.',
- detailUrl: '/showcase/wifi-note',
- website: 'https://wifinote.net',
- featured: true,
order: 4,
},
{