docs: Tuist 생성 프로젝트 관리 규칙 정리

Author: opficdev

.hermes/skills/devlog-architecture-harness/SKILL.md

@@ -28,7 +28,7 @@ Use this skill in the repository root when the task touches any of these areas:
 - Widget snapshot, App Group, or widget deep-link data flow.
 - Architecture diagrams, README architecture text, or PR architecture explanation.
 
-This repository is an Xcode workspace-based modular iOS app. There is no root `Package.swift`; modules are separate `.xcodeproj` entries under `DevLog.xcworkspace`.
+This repository is a Tuist-generated, workspace-based modular iOS app. There is no root `Package.swift`; module projects are generated from `Workspace.swift` and each module's `Project.swift`.
 
 ## Required project context
 

.hermes/skills/devlog-architecture-harness/references/devlog-architecture-flow.md

@@ -8,7 +8,7 @@ The goal is not to make the AI decide more architecture policy. The goal is to m
 
 Use this reference with `AGENTS.md` and `.hermes/skills/devlog-architecture-harness/SKILL.md`.
 
-This repository is an Xcode workspace-based modular iOS app. There is no root `Package.swift`; modules are separate `.xcodeproj` entries under `DevLog.xcworkspace`.
+This repository is a Tuist-generated, workspace-based modular iOS app. There is no root `Package.swift`; module projects are generated from `Workspace.swift` and each module's `Project.swift`.
 
 ## High-level harness flow
 

.hermes/skills/devlog-architecture-harness/references/devlog-workflow-rules.md

@@ -13,18 +13,18 @@ This reference holds DevLog-specific working rules that should live with the pro
 - Prefer Xcode Local MCP for iOS project code changes.
 - If Xcode Local MCP is unavailable or fails because of session transport, state that explicitly before using a fallback.
 - This repository is workspace-based. Prefer workspace/scheme context over standalone project builds when dependencies cross module projects.
-- CI truth lives in `.github/workflows/build.yml`: select Xcode 26.3, install Tuist with mise, run `tuist generate --no-open`, assert generated Xcode files are clean with `git diff --exit-code`, then build `DevLog.xcworkspace` scheme `DevLog` with `-resolvePackageDependencies`, `-skipPackagePluginValidation`, and `-skipMacroValidation`.
+- CI truth lives in `.github/workflows/build.yml`: select Xcode 26.3, install Tuist with mise, run `tuist generate --no-open`, then build `DevLog.xcworkspace` scheme `DevLogApp` with `-resolvePackageDependencies`, `-skipPackagePluginValidation`, and `-skipMacroValidation`.
 - CI is build validation, not a full test run, unless the workflow changes.
-- Avoid unrelated `Package.resolved` churn. Keep lockfile changes only when dependency resolution is the task.
+- Avoid unrelated generated project and `Package.resolved` churn. Generated Xcode workspace/project files should not be tracked unless the project explicitly changes that policy.
 
 ## Xcode project file work
 
-- Inspect Swift imports and `.xcodeproj/project.pbxproj` framework links together.
-- Validate touched `project.pbxproj` files with `plutil -lint`.
+- Inspect Swift imports and Tuist target dependencies together.
+- Validate generated project structure by rerunning `tuist generate --no-open` and building the workspace.
 - `plutil -lint` does not prove Xcode save behavior is healthy; for Xcode save crashes, inspect crash reports and project-reference call stacks.
 - Do not force a single `objectVersion` across projects. Treat Xcode's actual save output as the source of truth.
 - For synchronized-root cleanup, verify on copied files or a narrowed rule set before touching real project files.
-- When removing project-file objects, distinguish stale product references, real target links, orphan build files, and plugin churn.
+- When changing project structure, update the Tuist manifest first and treat generated Xcode project churn as disposable output.
 
 ## PR and review handling
 

AGENTS.md

@@ -27,7 +27,7 @@ These instructions apply only to the repository root.
 
 Use this harness before any task that changes module boundaries, file ownership, layer dependencies, DI assembly, repository/service contracts, widget data flow, Firebase dependency placement, or architecture documentation.
 
-Treat this repository as an Xcode workspace-based modular iOS app. There is no root `Package.swift`; modules are separate `.xcodeproj` entries under `DevLog.xcworkspace`.
+Treat this repository as a Tuist-generated, workspace-based modular iOS app. There is no root `Package.swift`; module projects are generated from `Workspace.swift` and each module's `Project.swift`.
 
 ### Mandatory flow
 
@@ -89,7 +89,7 @@ These may proceed after inspection when they do not change architecture meaning:
 - If iOS project code changes, test build with Xcode Local MCP.
 - If Xcode Local MCP is unavailable, state that explicitly before using a fallback.
 - Do not claim architecture work is complete without checking the diff scope.
-- Do not spend time on unrelated lockfile churn. Keep `Package.resolved` changes only when they are part of the requested task.
+- Do not spend time on unrelated generated project or lockfile churn. Keep generated workspace/project and `Package.resolved` changes out of source control unless they are part of an explicitly approved dependency-lock policy.
 - For Firebase Cloud Functions, deploy updated functions one by one separately.
 
 ## Canonical project rules

README.md

@@ -154,7 +154,7 @@ MVVM을 기반으로 하되, ViewModel 상태 관리에는 MVI 형태의 단방
 
 ## 개발 도구
 
-- Xcode 프로젝트와 워크스페이스는 Tuist manifest를 기준으로 생성
+- Xcode 프로젝트와 워크스페이스는 Tuist manifest를 기준으로 생성하며 Git은 생성물을 추적하지 않음
 - `.mise.toml`에서 Tuist 버전을 고정
 - `Project.swift`, `Workspace.swift`, `Tuist/ProjectDescriptionHelpers` 변경 후 아래 명령으로 Xcode 프로젝트 재생성
 
@@ -168,7 +168,6 @@ tuist generate --no-open
 
 ```text
 SwiftUI_DevLog/
-├── DevLog.xcworkspace
 ├── Tuist.swift
 ├── Workspace.swift
 ├── .mise.toml