klinsmaya/multica
1
0
Fork 0
mirror of https://gh-proxy.org/https://github.com/klinsmaya/multica.git synced 2026-11-08 01:16:45 +08:00
Code Issues Packages Projects Releases Wiki Activity
5,839 Commits 2,537 Branches 164 Tags
main
Commit Graph
3 Commits
Author SHA1 Message Date
Zain MehdiandClaude Opus 5 c99849d8a5 fix(mobile): re-apply app config to ios/ on every local iOS build (MUL-6206) (#6992) 
The remedy documented in apps/mobile/README.md for a claimed bundle
identifier — export EXPO_BUNDLE_IDENTIFIER_PROD, then re-run
`pnpm ios:mobile:device:prod:release` — has no effect after the first build.
`expo run:ios` prebuilds only when ios/ is missing: ensureNativeProjectAsync
in @expo/cli returns early when the directory exists, so config plugins never
re-run and the project keeps the old identifier.

The same freeze hides every other app.config.ts change. A checkout whose ios/
was generated once still had the template bundle id, an empty
AppIcon.appiconset, no CFBundleDisplayName, no CFBundleURLTypes and no
NSPhotoLibraryUsageDescription — while every build reported success.

Route every ios:* script through scripts/ios-run.sh, which prebuilds before
running. The wrapper inherits the caller's dotenv/cross-env so prebuild and
run resolve the same APP_ENV and bundle identifier; a bare prebuild in a
prod/staging script would rewrite the project to the dev variant.

--no-install is safe because run:ios installs pods itself when Podfile.lock is
stale. --clean is avoided because expo-build-properties sets
buildReactNativeFromSource, making a clean prebuild far too slow for the
edit/run loop.

scripts/ios-run.test.sh stubs pnpm on PATH and asserts the call sequence:
prebuild precedes run:ios, arguments forward to run:ios only, and a failed
prebuild aborts before run:ios. It runs in mobile's existing test task.


Claude-Session: https://claude.ai/code/session_01GfpPip2LPR1y9bKKEssGLG

Co-authored-by: Claude Opus 5 (1M context) <[email protected]>
 2026-08-16 23:58:39 +08:00
Jiayuan ZhangandClaude Opus 4.6 d4f5c5b16f feat: pivot to AI-native task management platform (#232) 
Replace the agent framework codebase with a new monorepo structure
for an AI-native Linear-like product where agents are first-class citizens.

New architecture:
- server/ — Go backend (Chi + gorilla/websocket + sqlc)
  - API server with REST routes for issues, agents, inbox, workspaces
  - WebSocket hub for real-time updates
  - Local daemon entry point for agent runtime connection
  - PostgreSQL migration with 13 tables (issue, agent, inbox, etc.)
  - WebSocket protocol types for server<->daemon communication
- apps/web/ — Next.js 16 frontend
  - Dashboard layout with sidebar navigation
  - Route skeleton: inbox, issues, agents, board, settings
- packages/ui/ — Preserved shadcn/ui design system (26+ components)
- packages/types/ — Full API contract types (Issue, Agent, Workspace, Inbox, Events)
- packages/sdk/ — REST ApiClient + WebSocket WSClient
- packages/store/ — Zustand stores (issue, agent, inbox, auth)
- packages/hooks/ — React hooks (useIssues, useAgents, useInbox, useRealtime)
- packages/utils/ — Shared utilities

Removed: apps/cli, apps/desktop, apps/mobile, apps/gateway,
packages/core, skills/, and all agent-framework code.

Co-authored-by: Claude Opus 4.6 <[email protected]>
 2026-03-20 17:55:49 +08:00
Naiyuan QingandClaude Opus 4.5 01c82b296d feat(mobile): 移动端初始化 
Co-Authored-By: Claude Opus 4.5 <[email protected]>
 2026-02-03 16:39:53 +08:00