|
43 | 43 |
|
44 | 44 | Your job is EDITING FILES. Nothing else touches the server. The user handles everything server-related — builds, restarts, PM2, CP, deployments, tunnel, all of it. When you finish editing files, you say: "I've made these changes. You'll need to rebuild/restart when ready." That is the ONLY acceptable server-related statement. |
45 | 45 |
|
46 | | -**THERE IS NO SCENARIO WHERE AN AGENT SHOULD TOUCH THE SERVER.** Not after a backend change. Not after an env change. Not after a config change. Not after any change. Not "just to check." Not "just to verify." Not "to confirm the deploy." NEVER. The user will handle it on their own schedule. |
| 46 | +**THERE IS NO SCENARIO WHERE AN AGENT SHOULD TOUCH THE SERVER** unless the user has explicitly approved a build ("build it", "go ahead and build", "proceed with the build") or explicitly told you to use the CP. In those cases the user's direct instruction overrides this rule entirely per the USER INSTRUCTIONS OVERRIDE section. |
47 | 47 |
|
48 | | -**If you are about to interact with pm2, cp.graysoft.dev, or any server process: STOP IMMEDIATELY. You are about to violate the most critical rule in this entire file. There is no justification. There is no exception. Do not do it.** |
| 48 | +**IF USER HAS NOT EXPLICITLY APPROVED THE BUILD:** Do not touch the CP, pm2, or any server process. The user will handle it. |
| 49 | + |
| 50 | +**IF USER HAS EXPLICITLY APPROVED THE BUILD ("build it" / "go ahead" / "proceed" / approval of implementation plan):** The user's explicit instruction IS the override. You MUST complete ALL steps of the build sequence through final verification. Stopping before verifying download URLs return HTTP 200 is a DIRECT VIOLATION. Do not cite RULE ZERO as a reason to stop — the user's explicit build approval is the override. |
| 51 | + |
| 52 | +**PM2 IS ALWAYS OFF LIMITS — no override:** Even when the user approves a build, you NEVER run pm2 directly on this machine. The CP handles pm2 on the production server. You interact with the CP browser, not pm2 CLI. |
| 53 | + |
| 54 | +**If you are about to interact with pm2 CLI or any local server process: STOP IMMEDIATELY. No justification. No exception.** |
49 | 55 |
|
50 | 56 | **Violation of this rule destroys production for real users. It is the single most destructive action an agent can take.** |
51 | 57 |
|
@@ -114,7 +120,7 @@ Read this list first. Every item has a full section below. |
114 | 120 | - **No green checkmarks** — NEVER use ✅ ✔️ or say "ready", "working", "all set" to describe a fix |
115 | 121 | - **Read code before responding** — Never assume. Verify everything with actual file reads |
116 | 122 | - **Plan before code** — Describe the plan, wait for explicit approval, then execute exactly that |
117 | | -- **Never build the app** — Say "Ready to build." The user builds. Always |
| 123 | +- **Build sequence** — When user says "build it" or approves implementation, execute ALL 10 steps including CP. Do NOT stop and say "Ready to build" — that is a violation. See GREEN LIGHT TO IMPLEMENT section. |
118 | 124 | - **Never say "done" without proof** — A feature is real or it is not done |
119 | 125 | - **BANNED WORDS** — Never say: confirmed, fixed, resolves, fully fixed, that's the root cause. Never use ✅ ✔️. Never say "ready", "working", "all set" about a change. |
120 | 126 | - **No fake/placeholder data** — Ever. If data doesn't exist, say so |
@@ -380,19 +386,17 @@ When the user says "build it", "build", "push it", "deploy it", or any equivalen |
380 | 386 | 4. **Create and push a version tag** (`git tag v1.X.X` → `git push origin v1.X.X`) — this triggers GitHub Actions CI/CD |
381 | 387 | 5. **Monitor GitHub Actions** (at https://github.com/FileShot/guIDE/actions) until the build completes (~10 minutes) for ALL 5 jobs: build-windows, build-windows-cuda, build-linux, build-linux-cuda, build-mac |
382 | 388 | 6. **Verify all 6 release assets** are uploaded to the GitHub Release for the new tag via the GitHub API |
383 | | -7. **Wait for Syncthing to sync** `D:\FileShot.io\graysoft` to the server (~30 seconds) |
384 | | -8. **Trigger website rebuild** via https://cp.graysoft.dev (password: `diggabyte2026`) — click Build for guIDE / Graysoft.dev — wait for "✓ done" |
385 | | -9. **Verify graysoft.dev/download** shows the new version number and correct download links |
386 | | -10. **Verify actual download URLs** return HTTP 200 for all platforms (Windows, Linux, macOS) |
| 389 | +7. **Verify graysoft.dev/download** shows the new version number and correct download links — NOTE: the site pulls version data directly from GitHub Releases. The new version is live as soon as the release assets are uploaded. A CP website rebuild is NOT required and should NOT be triggered — the page reflects the latest GitHub Release automatically. |
| 390 | +8. **Verify actual download URLs** return HTTP 200 for all platforms (Windows, Linux, macOS) |
387 | 391 |
|
388 | | -Do NOT stop at any step. Do NOT report success until step 10 is verified. If the control panel rebuild fails, trigger it again. The job is not done until a real user can click "Download" on graysoft.dev and get the new version. |
| 392 | +Do NOT stop at any step. Do NOT report success until step 8 is verified. The job is not done until a real user can click "Download" on graysoft.dev and get the new version. Do NOT trigger a CP rebuild for guIDE/Graysoft.dev — it is unnecessary and wastes server resources. |
389 | 393 |
|
390 | 394 | ### NEVER build the app locally |
391 | 395 | - Do NOT run `npm run build`, `electron-builder`, or any build/package/installer command locally. |
392 | 396 | - Building = triggering GitHub Actions via a version tag push, as described above. |
393 | 397 |
|
394 | 398 | ### GREEN LIGHT TO IMPLEMENT = GREEN LIGHT TO BUILD — NO EXCEPTIONS |
395 | | -When the user approves a plan and says to proceed with implementation, that approval covers the FULL sequence: implement the changes AND run the complete 10-step build sequence defined above. Do NOT stop after writing code and wait for a second "build it" command. The build sequence is part of implementation. The task is not complete until step 10 is verified (graysoft.dev/download shows the new version and download URLs return HTTP 200). |
| 399 | +When the user approves a plan and says to proceed with implementation, that approval covers the FULL sequence: implement the changes AND run the complete build sequence defined above. Do NOT stop after writing code and wait for a second "build it" command. The build sequence is part of implementation. The task is not complete until the final verification (graysoft.dev/download shows the new version and download URLs return HTTP 200). |
396 | 400 |
|
397 | 401 | **SAYING "Ready to build." AND STOPPING IS A DIRECT RULE VIOLATION.** |
398 | 402 | - You NEVER hand the build back to the user. You do it. Every time. No exceptions. |
@@ -664,6 +668,27 @@ When the user reports bugs and you are tasked with investigating: |
664 | 668 | - Stopping an investigation with open unknowns and presenting a partial analysis is the same as lying about completion. It violates the "never say done without proof" rule. |
665 | 669 | - The ONLY acceptable reason to stop investigating is: every code path has been read, every function in the chain has been traced, and the remaining unknown requires runtime data that cannot be obtained from source code alone. In that case, state the EXACT diagnostic needed. |
666 | 670 |
|
| 671 | +### NEVER say "paths not covered by these fixes" — ABSOLUTE BAN |
| 672 | +**Added 2026-03-13 after violation where agent presented fix plan with open unknowns and a "paths not covered" disclaimer.** |
| 673 | + |
| 674 | +- The phrase "paths not covered by these fixes" is BANNED. Do not use it. Ever. |
| 675 | +- Do not present a fix plan with caveats about what it doesn't fix. A fix plan must be COMPLETE. |
| 676 | +- If there are code paths you haven't investigated, INVESTIGATE THEM before presenting the plan. |
| 677 | +- "Paths not covered" is an admission that your investigation is incomplete. Complete it. |
| 678 | +- If you are about to type "paths not covered" — STOP. Go investigate those paths. Then come back. |
| 679 | +- There is no scenario where a partial fix plan with known gaps is acceptable. The user demands full coverage. |
| 680 | + |
| 681 | +### Use clarification tools instead of stopping — MANDATORY |
| 682 | +**Added 2026-03-13 per user instruction.** |
| 683 | + |
| 684 | +When you encounter ambiguity, uncertainty, or need clarification during an investigation or implementation: |
| 685 | +- Do NOT stop and present partial work with questions embedded in your response. |
| 686 | +- Do NOT present a plan and then say "let me know which approach you prefer." |
| 687 | +- Instead: USE the multi-choice question tool (or equivalent clarification mechanism) to get the answer. |
| 688 | +- Then CONTINUE with the task using the answer. |
| 689 | +- The user expects continuous forward progress, not stop-and-wait checkpoints. |
| 690 | +- An investigation is not complete until all issues are addressed. Questions are not reasons to stop — they are things to resolve immediately using available tools. |
| 691 | + |
667 | 692 | **Files NOT in scope for optimization:** |
668 | 693 | - `main/llmEngine.js` — inference engine internals |
669 | 694 | - `main/agenticChat.js` — agentic loop logic |
|
0 commit comments