You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
- Do not pull the repository to the user's Mac for development, testing, or builds unless the user explicitly asks for local work.
11
-
- The local machine may be used only for conversation, coordination, or temporary non-source artifacts when unavoidable.
7
+
- Do feature development, testing, and builds locally in `/Users/beetle/Desktop/code/Pixel`.
8
+
- Use the remote server only for deployment, production builds, production service restarts, and post-deploy verification unless the user explicitly asks for server-side development.
9
+
- Production server: `root@52.77.228.143`.
10
+
- Server repository path for deployment: `/opt/pixel-src`.
11
+
- Server service path: `/opt/pixel`.
12
+
- Do not use the production runtime directory as a development workspace.
12
13
13
14
## Branch And Worktree Flow
14
15
15
-
- Every new requirement starts from the latest GitHub `origin/main`.
16
-
- Fetch first, then create a dedicated feature branch from `origin/main`.
17
-
- Use one isolated worktree per requirement.
16
+
- Every new requirement starts locally from the latest GitHub `origin/main`.
17
+
- Fetch first, then create a dedicated local feature branch from `origin/main`.
18
+
- Use one dedicated branch per requirement.
19
+
- Use a local isolated worktree only when multiple requirements or parallel branches need to be active at the same time.
18
20
- Branch naming:
19
21
-`feat/<feature-name>` for features.
20
22
-`fix/<bug-name>` for bug fixes.
@@ -26,10 +28,18 @@ These rules are project-specific and apply to all agent work on Pixel.
@@ -74,14 +84,14 @@ The controller agent is responsible for coordination:
74
84
75
85
- Use test-driven development for code behavior changes whenever practical.
76
86
- Write or update tests before production code for new behavior.
77
-
-Prefer running most verification in the local development environment or an isolated test environment before handoff.
78
-
- In this project, "local development environment" means the feature worktree on the development server or another explicitly approved non-production environment, not the production runtime directory.
79
-
-Development-environment tests are allowed by default when they are scoped, reproducible, and do not mutate production data.
80
-
- Allowed by default on the development environment:
87
+
-Run development verification locally before handoff.
88
+
- In this project, "local development environment" means the local repository or local feature worktree, not the production server runtime directory.
89
+
-Local development tests are allowed by default when they are scoped, reproducible, and do not mutate production data.
90
+
- Allowed by default locally:
81
91
- Targeted backend unit tests, for example a specific Go package or `-run` pattern.
82
92
- Targeted frontend tests, for example a specific Vitest spec.
83
93
- Static checks such as `gofmt`, `git diff --check`, type checks, and lint checks.
84
-
- Frontend/backend builds when needed to prove compile correctness, as long as they run from the feature worktree and do not restart production services.
94
+
- Frontend/backend builds when needed to prove compile correctness, as long as they run from the local feature branch/worktree and do not restart production services.
85
95
- Require explicit user approval before running:
86
96
- Load tests, pressure tests, benchmark loops, or high-concurrency checks.
87
97
- Full-suite tests known to be long-running or resource-heavy.
@@ -100,24 +110,25 @@ The controller agent is responsible for coordination:
100
110
101
111
Feature branches are not deployed automatically.
102
112
103
-
1. Develop in the feature worktree.
104
-
2. Run relevant tests and verification.
113
+
1. Develop locally on the feature branch or local feature worktree.
114
+
2. Run relevant local tests and verification.
105
115
3. Commit changes on the feature branch.
106
116
4. Push the feature branch to GitHub.
107
117
5. Tell the user the branch name, summary, changed files, and verification results.
108
118
6. Wait for user review or explicit approval.
109
119
7. Merge to `main` only after approval.
110
-
8.Deploy from`main`.
111
-
9. Build the production binary/assets.
120
+
8.On the server, pull the approved GitHub`main`.
121
+
9. Build the production binary/assets on the server from the pulled GitHub code.
112
122
10. Restart services.
113
123
11. Verify production behavior.
114
124
12. Create a version tag when the deployment is accepted.
115
125
116
126
## Production Deployment Rules
117
127
118
-
- Deployments happen on the server, not from the user's Mac.
128
+
- Deployments happen on the server by pulling from GitHub, not by copying uncommitted local files.
119
129
- Do not deploy a feature branch directly unless the user explicitly requests it.
120
130
- Prefer deploying from `main` after merge.
131
+
- Before deployment, make sure the intended commits have been pushed to GitHub.
121
132
- Keep backups of service config files before editing operational configuration.
0 commit comments