Skip to content

Epic: make LumiBase a must-install dependency (Vite/Prisma-style installs) #331

Open
0 of 3 issues completed
Open
Epic: make LumiBase a must-install dependency (Vite/Prisma-style installs)#331
0 of 3 issues completed
Labels
enhancementNew feature or request

Description

@khuepm
khuepm
opened on Aug 2, 2026

🔎 Reviewer — Điều phối tiếp theo, 2026-09-13

Theo yêu cầu chủ repo: B02 vẫn tiếp tục; chia việc mới tránh chồng ownership. Baseline lập kế hoạch main d280771af520267464e48efa4fa87d6623b11bc4.

Lượt Issue Trạng thái / đầu ra
A02 #332 Đã merge PR #468, issue Completed; là baseline starter cho A03.
A03 #334 Ready, chờ phiên lane A ACK. Example cài độc lập + SDK lumibase mặc định + tutorial EN/VI; handoff #334 (comment).
B02 #454 / PR #471 Đang tiếp tục audit/repro theo thông tin owner. Implementation còn blocked bởi G1 acceptance, #472 và exact-file grant. Không thay owner/checkout hoặc mở G3.
C03 #453 Ready, chờ verifier ACK. Nghiệm thu G1 trên main với DB riêng; handoff #453 (comment).
G2-CAP #472 Work item capability đã tạo, blocking #454. Contract chuẩn bị được ngay; lane B triển khai theo lượt sau G1, trước G2 implementation; không có owner production thứ hai sửa harness.
A04 #333 Chờ A03, nhận onboarding tổng thể; không sửa tutorial đồng thời A03.
B03 #455 Giữ blocked đến G1/G2 accepted; #359 theo functional gates hiện có.

Giữ tối đa hai implementer A/B và một verifier C. Chưa có ACK cho A03/C03/#472, không tuyên bố các phiên mới đã chạy. Không tạo thêm task Codex trong lượt này. Handoff ghi exact paths, đầu ra, bằng chứng và giới hạn; issue là nguồn scope, Project #7 là nguồn trạng thái.

#469 (audit crash với site giả) và #470 (setup-token startup) giữ issue riêng, ưu tiên triage an toàn trước release/expose; chưa được phân production owner trong lượt này. Khi nhận sửa phải đối chiếu auth/audit ownership của #472/B02 và serve/setup của #470, không gộp vào A03. #448 thu bằng chứng install của A03; #212 vẫn quyết định release. PR #467 giữ phần dependency/lockfile chung theo lượt tích hợp.

Chỉ thị Git hiện hành: chủ repo yêu cầu không tạo nhánh mới, push thẳng main. Điều này thay thế hướng dẫn tạo branch ở phần lịch sử cho công việc mới; thay đổi được kiểm tra và tích hợp tuần tự lên main, giữ nguyên B02 đang làm và các file chưa commit. Không đổi nhánh/reset/stash working tree người khác. Việc chia scope không tự nghiệm thu, đóng issue hoặc phát hành.

Đây là cập nhật kế hoạch/handoff; chưa chạy lại runtime/tests trong phiên chia việc này.

Phần dưới là kế hoạch và lịch sử trước đợt này; trạng thái/handoff mới nhất ở bảng trên.

🔎 Reviewer — role identification and language protocol (owner-approved 2026-09-07)

Identity and language

  • The pilot uses one independent reviewer and two implementers. All participants share the GitHub account khuepm; the account name does not identify the role.
  • Every reviewer-authored GitHub comment, PR review, inline review comment, issue/project update and review document starts with 🔎 Reviewer (Markdown heading syntax may precede the prefix).
  • Reviewer feedback and coordination records are written in English.
  • Implementers write their responses, PR titles/descriptions, PR comments, issue comments and project updates in Vietnamese. Code identifiers, commands, logs and quoted evidence retain their original language.
  • Do not infer authorship of old comments from khuepm. Only relabel historical feedback whose authorship is established from this review session.

Review records

  • Store review Markdown in /Users/khuepm/workplace/Lumibase/docs/review-agent.
  • Use YYYY-MM-DD-pr-NNN-HEAD.md for commit-specific reviews. Preserve earlier records and explicitly supersede findings when new evidence changes the verdict.
  • Each review names the canonical issue, PR URL, full inspected head SHA, verdict, evidence, applicable DoD gates and remaining work.
  • Distinguish reviewer-run checks, CI results, implementer claims and unverified cases. Missing or skipped evidence is not pass.
  • Publish the review to its PR and link the outcome from the canonical issue. Issue Epic: make LumiBase a must-install dependency (Vite/Prisma-style installs) #331 is the pilot's coordination source; do not create a competing roadmap.

Responsibilities

  • The reviewer assesses scope, correctness, integration interactions and the complete applicable DoD. Implementers fix production code and return updated PR heads with evidence.
  • One implementer owns one active work item in an isolated checkout. Respect the file grants and dependencies recorded in the canonical issue.
  • New commits invalidate affected earlier review conclusions. Check the actual diff and relevant tests before updating a verdict.
  • Owner approval of the plan is distinct from PR acceptance. Merge, release, deployment and issue closure follow their existing authorization and acceptance gates.
  • A COMMENT review with a written changes-required verdict is not an approval. The shared author account may prevent GitHub's formal self-review states.

Current review round

The owner explicitly selected all four PRs on 2026-09-07: #456, #462, #458 and #457. Earlier references to three PRs are superseded.

Project đã cập nhật theo yêu cầu khuepm ngày 2026-09-06: mở board #7. khuepm đã duyệt scope và yêu cầu bắt đầu giao việc. Handoff A-01 tại #450, B-01 tại #453; chờ phiên nhận việc ACK, chưa có implementer chạy.

Điều phối đã duyệt — 2026-09-06 — HANDOFF ĐỢT ĐẦU ĐÃ ĐĂNG

Trạng thái: khuepm đã duyệt trong phiên verifier ngày 2026-09-06. Devin nhận vai trò verifier kiêm điều phối GitHub; scope con được chuẩn hóa, G1 #453 / G2 #454 / G3 #455 được tạo sau recheck inventory và source. A-01 #450 và B-01 #453 đã có handoff để chuyển sang phiên riêng; chưa có session ACK nên không tuyên bố đang implement. Chưa đặt deadline calendar, đổi milestone, publish/deploy hoặc nghiệm thu hoàn tất. Epic/project hiện có được tái sử dụng.

Mục tiêu và trạng thái đã xác minh

Mục tiêu sản phẩm: người mới cài LumiBase, có website + Studio với nội dung mẫu, sửa/xem trước/xuất bản được, rồi dùng LumiBase cho dự án tiếp theo. Downloads là chỉ số phân phối; activation, website hoạt động và dự án thứ hai là chỉ số sử dụng thật.

GitHub là nguồn điều phối chính

  • Issue: scope đã duyệt, acceptance criteria, dependencies và owner của từng việc. Một kết quả có một issue chuẩn.
  • Epic Epic: make LumiBase a must-install dependency (Vite/Prisma-style installs) #331: quyết định chung về adoption, thứ tự ưu tiên, bản đồ liên kết công việc; không sao chép toàn bộ checklist từng issue.
  • v1.0.0 readiness — release exit checklist #212: tiếp tục là nguồn quyết định release readiness. Kế hoạch adoption không tự bỏ gate release.
  • Project hiện có: sau khi đọc được quyền, tái sử dụng/điều chỉnh views cho Adoption, Content OS, Release và Deferred. Status và timeline nằm trên board; nội dung yêu cầu nằm trong issues. Chưa thay tên/xoá project cũ.
  • Repo: code, contract, tài liệu/spec được version hoá và liên kết từ issue. Sau thay đổi scope đã duyệt, cập nhật specs/EN-VI tương ứng; không duy trì một roadmap độc lập trong chat.
  • Comments: nhật ký handoff, câu hỏi scope và bằng chứng review. Coordinator tổng hợp quyết định vào issue chuẩn; không để hai comments trở thành hai bộ yêu cầu khác nhau.
  • Nếu board chưa truy cập được, dùng mục Execution trong issue làm nơi ghi trạng thái tạm thời; khi nối board thì chuyển trạng thái sang board, không duy trì hai trạng thái thủ công.

Bản đồ tái sử dụng và điều chỉnh đã duyệt

Issue/PR hiện có Quyết định đã duyệt
#331 Giữ làm epic adoption; cập nhật hướng package client chính là lumibase, thay tư duy chỉ thêm dependency bằng website chạy được.
#332 Mở rộng acceptance thành starter thực sự kết nối CMS + Studio, có seed content. Giữ một scaffold implementation, tránh chỉ thêm dependencies.
#334 Default import trong consumer/example mới là lumibase; giữ tương thích @lumibase/sdk. Example chạy độc lập, không phụ thuộc workspace:* hay setup thủ công không được ghi rõ.
#333 Hướng dẫn bám starter đã nghiệm thu; không quảng bá command/URL chưa chạy. Giữ EN/VI đồng bộ.
#335 Giữ research-only/deferred; chưa triển khai embedded/server npm package.
#448 Giữ package/RC validation đã có và bằng chứng đã pass; bổ sung cold-install → CMS/Studio → publish → frontend read cho starter mới.
#450 Giữ bug riêng về Cloudflare dependency compatibility. Cùng owner với scaffolder; không biến thành ticket thứ hai cho starter mới.
#449, #451, #212 Giữ release gates. Scope #451 có Pages và desktop/mobile; thay đổi local hiện có phải đối chiếu trước. Không đóng cả #451 khi mới sửa Pages.
#427 Tái sử dụng cho tính trung thực của DB test results; không viết lại một “QA harness” trùng. Khi ghi lỗi kết nối phải redact password/token, không in nguyên DATABASE_URL.
#361, #344–347 Giữ epic và các việc MCP protocol. Đính chính factual claim “cả hai transport đều qua harness”. Sửa functional governance trước; không đánh đồng OAuth/resources/SSE với việc approve thực sự chạy lệnh.
#359 Tái sử dụng cho reference website và proof intent → drift → agent → approve → publish → verify. Đã duyệt chuẩn bị proof sớm sau gate chức năng; giữ milestone Post-v1 và gate public deployment/release.
#342 Giữ làm tracker benchmark/cache; #359 liên kết kết quả đo ở đây, không sao chép chương trình đo.
PR #265 Marketplace đang có PR mở. Kiểm tra diff còn lại so với main trước; không đóng “duplicate” hoặc giao rebuild marketplace chỉ dựa vào title cũ.
PR #416, #417 Dependency updates đang mở, có thể đụng manifest/lockfile. Tích hợp theo lượt riêng, tránh gây nhiễu baseline của starter/Studio.
#362–364 và con Giữ roadmap GitOps/realtime/authz; không đổi scope hoặc lịch ngầm vì đợt adoption này.

Các delta đã duyệt; recheck 2026-09-06 không thấy ticket chuyên trách trùng. G1–G3 đã có issue chuẩn; U1/E1 vẫn phải qua audit trước khi tạo:

  1. G1 — fix(agent): G1 approval decision must execute or resume the governed action #453 — approval decision → execution/resume và dependency wiring; không trả success khi thiếu service. Luồng approval concurrency/race đã từng sửa không đồng nghĩa approval roundtrip đã đúng.
  2. G2 — fix(mcp): G2 executable tool schemas and consistent governed transport contracts #454 — contract tool/input schema và thực thi autonomy nhất quán giữa transport; giữ token/RBAC constraints. Liên kết Epic: MCP spec compliance and interop (post-v1) #361.
  3. G3 — fix(agent): G3 connect reconciler goals to a verified translation repair loop #455 — nối reconciler goal đến worker, sửa một ca thiếu bản dịch và kiểm tra drift đã hết. Là implementation dependency của proof proof: reference application + public benchmark for the Content OS claims #359, không tạo epic proof mới.
  4. U1 — nối thao tác editor preview/review/publish với starter/reference website. Chỉ mở sau khi đối chiếu backend/editorial đã có; không xây lại editorial engine.
  5. E1 — extension discover/install/render/update/uninstall trên instance mới. Chỉ mở phần delta sau audit PR Claude/marketplace extension install vote 4oi69c #265; deferred đến khi starter và vòng Content OS đầu tiên qua gate.

Phân vai đã duyệt và điều chỉnh theo chỉ định verifier

Tên model là lựa chọn triển khai dự kiến, không phải tuyên bố chúng đã được kết nối hoặc đã nhận việc. Khởi đầu tối đa 2 implementer + 1 verifier; một implementer chỉ giữ một work item đang thực hiện.

Vai trò Đề xuất phiên LLM Trách nhiệm và ranh giới
Coordinator / integration Devin trong phiên verifier hiện tại, được khuepm giao quyền GitHub Chuẩn hoá issue, chốt contract, cấp quyền sở hữu file, review diff, chạy nghiệm thu cuối và cập nhật GitHub. Commit/push main chỉ thực hiện khi khuepm yêu cầu lượt tích hợp cụ thể; lần giao việc này không bao gồm push. Chịu trách nhiệm gate cuối.
A — Developer experience Một phiên Codex riêng #450 rồi #332, #334. Chủ yếu packages/create-lumibase, packages/cli, packages/sdk, examples/nextjs-blog. Chỉ chỉnh SDK khi cần cho acceptance. Đợt sau nhận U1 với phạm vi Studio riêng đã cấp.
B — Agent governance Một phiên Claude Code G1 rồi G2 rồi G3. Chủ yếu CMS agent/MCP/harness services/routes, packages/mcp-server, packages/ai-skills. Không tự sửa scaffold hay editor.
C — Independent verification Devin trong phiên này, độc lập với A/B Reproduce trước sửa; #427; nghiệm thu #448/#359; negative tests tenant/permissions/approval; browser walkthrough. Bắt buộc rà toàn bộ DoD trên PR head và ghi bằng chứng vào PR/issue trước nghiệm thu. Chỉ sở hữu test files được cấp riêng, không tự sửa implementation rồi tự pass.

Nếu Claude/Gemini chưa có connector/CLI/session khả dụng, giao bằng prompt/handoff do coordinator soạn; khuepm chuyển tới phiên tương ứng và đưa kết quả trở lại. Không coi một GitHub assignee là agent đã chạy. Có thể thay bằng phiên LLM đang kết nối mà không đổi contract của công việc. Không tự mua dịch vụ hay dùng credential của tài khoản khác.

Quy tắc chống trùng và conflict — implementer bàn giao bằng PR

  1. Implementer dùng checkout riêng, tạo branch feature/<issue>-<description> từ base SHA đã chốt; được commit, push branch và mở/cập nhật PR vào main. Bắt buộc gắn PR vào issue trên GitHub (PR ghi Refs #issue, issue có comment URL PR; thêm Development link nếu có). Không tự merge, push thẳng main hoặc đóng issue; coordinator/owner tích hợp sau verifier nghiệm thu.
  2. Không cho nhiều LLM sửa chung working tree. Checkout hiện tại có thay đổi chưa commit; coi các file đó là đang được giữ, không reset/stash/overwrite hay trộn vào commit của nhiệm vụ khác.
  3. Trước dispatch: re-read issue body/comments, kiểm tra owner đang hoạt động, PR liên quan và diff main mới nhất. Coordinator ghi Agent Owner, session link, base SHA, allowed paths, dependencies, verifier và lượt handoff trên issue. Khi chưa có record giao việc thì chưa được bắt đầu.
  4. Files dễ conflict do coordinator giữ mặc định: root package.json, pnpm-lock.yaml, pnpm-workspace.yaml, .github/workflows/*, migration numbering/journal, packages/contracts, AGENTS, CHANGELOG và các docs/spec dùng chung. Cần sửa thì yêu cầu coordinator cấp từng file/đợt, không tự mở rộng scope.
  5. Backend owner có CMS services/routes; DX owner có packages/frontend; QA owner có test paths tách biệt. Contract API/SDK được chốt trước khi hai phía triển khai song song. Docs chỉ sửa sau contract đã chốt, ghi rõ cặp EN/VI và stamp.
  6. Handoff luôn ghi PR URL đã gắn vào issue + base SHA + PR head SHA + diff + tests/exit codes + môi trường + phần chưa kiểm chứng. Implementer không bắt buộc tự check toàn bộ DoD; verifier bắt buộc rà toàn bộ DoD và ghi bằng chứng cho từng mục áp dụng trước khi nghiệm thu. Khi main thay đổi, coordinator kiểm tra conflict và chạy lại các checks bị ảnh hưởng trên trạng thái đã tích hợp; không dùng kết quả cũ để chứng minh code mới.
  7. Issue chỉ đóng sau verifier hoàn tất DoD, coordinator nghiệm thu và main CI trên commit đã tích hợp xanh, cùng các acceptance/release gate còn lại. Không dùng auto-closing keyword để đóng sớm khi còn gate. Thất bại → ghi rõ blocker và giữ mở. Không force-push, không bỏ hooks để đạt deadline.
  8. Existing PR Claude/marketplace extension install vote 4oi69c #265/chore(deps): bump framer-motion from 12.43.0 to 13.1.1 #416/chore(deps-dev): bump typescript from 5.9.3 to 7.0.2 #417 được reconcile riêng; không đóng/merge hàng loạt. Các yêu cầu cũ được giữ trong lịch sử; thay đổi scope có lý do và được đưa vào issue chuẩn.

PR handoff and DoD responsibility — owner amendment 2026-09-06

This amendment supersedes the earlier patch-only / no-branch / no-PR handoff under #331. Scope, file ownership, baseline and dependency gates are unchanged.

  • Implementers may create a task branch (feature/<issue>-<description>) from the assigned baseline in an isolated checkout, commit, push that branch and open/update a PR targeting main. Preserve others work; no force-push, hook bypass, direct main push, self-merge or self-closing the issue. A draft PR is allowed while work is incomplete.
  • Every new PR MUST be linked back to its canonical issue on GitHub immediately: put Refs #ISSUE_NUMBER in the PR body and post a comment containing the PR URL on that issue. Use the Development link too where available. A PR URL only in chat is not a handoff. Avoid auto-closing keywords while post-merge CI, shipping or other acceptance gates remain outstanding.
  • PR handoff MUST include base SHA, current PR head SHA, scope/changed paths, reproduction, test commands with exit codes, environment and known failures/skips/unverified work. Keep the same PR updated for review fixes; report the new head SHA so the verifier does not approve stale evidence.
  • Implementers are NOT required to audit or complete the full DoD checklist before handing off a PR. This does not waive scoped tests, acceptance criteria, repository safety rules or commit/CI hooks. Report the DoD review as pending verifier, not as passed.
  • The independent verifier MUST review the entire .kiro/steering/definition-of-done.md against the actual PR head, check every applicable item and record pass/fail/blocked or n/a with a reason and evidence on the PR, linked from the issue. This includes code/tests, setup-impact registry (including n/a), tenant/RBAC/runtime safety, shell impact, dependencies, specs, EN/VI docs, tutorials and applicable release checks. Missing evidence is not pass.
  • DoD gaps are returned to the implementer/coordinator with exact-file grants where needed; verifier ownership of the checklist does not require the verifier to author and self-approve implementation fixes. Recheck affected gates after new commits and on the integrated main commit. Do not accept/mark Done/close the issue until verifier DoD and remaining CI/release acceptance gates are satisfied.
  • A linked draft PR alone does not mark the work In Review. The coordinator moves it there after the implementer requests review and supplies the handoff. Only an authorized coordinator/owner may merge after verification; this amendment does not authorize deployment or release promotion.

Gate nghiệm thu và thứ tự giao

Đợt 0 — baseline và contracts: reconcile edits local, RC1 evidence và pending PRs; QA tái hiện các gap có thật; chốt template đầu tiên Next.js + backend/Studio provisioning có prerequisite rõ. Chốt approval/tool contract và file ownership. Lỗi mới phát hiện phải được xác minh trên baseline trước khi thành requirement.

Đợt 1 — hai luồng độc lập: A sửa blocker #450 rồi starter/consumer #332/#334; B sửa G1/G2; C kiểm thử #427, package/API và negative paths trên tài nguyên test riêng. Docker/Studio/workflow changes đi qua coordinator để không đụng các edits đã có.

Đợt 2 — nối sản phẩm: A nhận U1 nối editor với website; B nhận G3 closed-loop một bản dịch; C nghiệm thu #448/#359 từ clean install. Docs #333 cập nhật sau hành vi đã chốt; #449 bao phủ release-wide docs/preflight.

Đợt 3 — chứng minh và mở rộng: reference website, demo quay thật, sử dụng thử bởi người ngoài repo; đo activation và dự án thứ hai. Sau đó mới tăng đầu tư E1/marketplace và các roadmap deferred.

Không ghi deadline calendar giả khi chưa biết số phiên LLM, thời gian khuepm dành cho handoff và quyền hạ tầng. Sau một nhiệm vụ nhỏ ở mỗi lane, coordinator dùng thời gian thực tế để đề xuất forecast trên board; thứ tự dependency/gate được chốt trước lịch ngày. Bug ảnh hưởng guarantee đã quảng bá được triage với #212; protocol/features additive không tự biến thành blocker v1.

Bằng chứng cần có:

  • Website: gói được pack/publish → cài vào thư mục mới không workspace:* → backend/Studio reachable → tạo nội dung → preview → publish → đọc bằng public/least-privilege client → tenant khác không đọc được.
  • Governance: tool schema dùng được trong MCP client thật → dangerous action chờ duyệt → reviewer quyết định → execution/resume có side effect mong đợi → retry không lặp tác động → audit/provenance. L0 không ghi và L1 cần duyệt đúng contract; không trả success-shaped stub.
  • Closed loop: thiếu bản dịch → drift → goal → worker → draft → approval → publish → drift hết; lỗi provider/worker phải hiển thị và có xử lý retry được kiểm tra.
  • QA ghi rõ unit/mock, DB integration, browser, real model và runtime nào đã chạy; skip không ghi thành pass. Dùng DB riêng, không reset DB người dùng. Gói chưa phát hành được kiểm bằng tarball; chỉ khẳng định published-install khi đã kiểm đúng artifact registry.
  • Release: tiếp tục theo v1.0.0 readiness — release exit checklist #212/v1 RC: validate unified npm packages and scaffolder compatibility #448–451; nghiệm thu main không tự đồng nghĩa được đẩy stable tag hay deploy production.

Execution record — handoff 2026-09-06

Mẫu lệnh giao việc cho một LLM

Read the approved scope and latest comments of ISSUE_URL. Read AGENTS.md.
Coordinator/verifier: this Devin session authorized by khuepm. Agent owner: OWNER / SESSION_URL.
Baseline: BASE_SHA. Allowed files: EXPLICIT_PATHS. Dependencies: ISSUE_IDS.
You are not alone in the codebase. Do not revert others' edits.
Use your assigned isolated checkout. Create a task branch from BASE_SHA; commit and push that branch, then open/update a PR targeting main. No direct main push, self-merge or force-push.
First reproduce the reported behavior and report mismatches with the issue.
Implement only the accepted scope; request a scope change before touching reserved files.
Acceptance: OBSERVABLE_OUTCOMES. Verification commands/environment: EXPLICIT_CHECKS.
Link every new PR on GitHub: PR body Refs #ISSUE_NUMBER plus a PR URL comment on the issue.
Return PR URL, base/head SHAs, changed paths, test outputs/exit codes, limitations and reproduction steps.
Full DoD self-review is optional for implementers; independent verifier DoD review is mandatory.
Do not mark the issue Done, close it or merge your own PR.

Quyết định khuepm đã duyệt

  • Duyệt GitHub làm nguồn điều phối và mô hình coordinator + 2 implementer + 1 verifier.
  • Duyệt giữ lumibase là client chính, nâng feat(create-lumibase): scaffold a working Next.js website with CMS, Studio and seed content #332 thành starter thật và thứ tự ba đợt triển khai sau baseline.
  • Sửa đổi đã duyệt: implementer được tạo branch, commit/push branch và mở PR từ checkout riêng; bắt buộc gắn PR vào issue. Coordinator/owner giữ quyền merge/tích hợp main sau nghiệm thu; implementer không tự merge/push main.
  • Implementer có thể không tự check toàn bộ DoD; verifier bắt buộc check toàn bộ DoD, ghi bằng chứng và xử lý các mục thiếu trước khi nghiệm thu.
  • Cập nhật scope issue con, tạo đúng các delta còn thiếu, cấp task đầu tiên và cấu hình board sau khi quyền Projects khả dụng. Các estimate sẽ được hiệu chỉnh theo kết quả đợt đầu.
Lịch sử yêu cầu trước ngày 2026-09-06 — giữ nguyên để đối chiếu; không dùng phần này làm lệnh dispatch mới

Problem

High npm download counts (Vite-style) come from being a day-to-day project dependency, not from splitting repos. Today LumiBase is primarily deploy the CMS (Docker / Workers / monorepo). create-lumibase scaffolds a minimal Hono + Drizzle starter with zero @lumibase/* dependencies. Public install surfaces are thin (@lumibase/sdk, @lumibase/extension-sdk, create-lumibase) — there is no default loop where every project runs pnpm add something LumiBase-owned.

Decision so far (Prisma-CLI path)

  • Unscoped lumibase CLI (packages/cli) as a devDependency: init / types / doctor (MVP in progress on feat/lumibase-cli — do not reopen as a child of this epic).
  • @lumibase/sdk as the runtime / types client for consumer apps.

Keep create-lumibase as the scaffold implementation; lumibase init delegates to it so npm create lumibase and the CLI cannot drift.

Out of scope for this epic (v0.x)

  • Payload-style embeddable CMS-in-Next packages.
  • Directus-style publishable full server package on npm (naming also collides with the unscoped CLI).

Track those as a separate spike child issue only.

Success metrics

  • Scaffolded / consumer projects list lumibase and/or @lumibase/sdk in package.json.
  • Docs lead with npm i -D lumibase (or equivalent) for the day-to-day loop.
  • Examples/tutorials show CI lumibase types --check where typegen applies.

Child issues

Context

From product research session comparing Vite / Prisma / Payload / Directus / Sanity install models vs current LumiBase consumption.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions