fix(fortran): parse args through cpp macros (#2077)

.claude/rules/ci-healing.md

@@ -0,0 +1,18 @@
+---
+description: "Instructions for automated CI monitoring and self-healing"
+globs: "*"
+---
+# CI Monitoring and Self-Healing Directive
+
+**CRITICAL INSTRUCTION: Never push code and forget about it.**
+
+Whenever you push code to a branch, you MUST automatically monitor the GitHub Actions CI pipeline to ensure it passes. Do not rely on the user to tell you if the CI failed. 
+
+**Steps to follow after pushing code:**
+1. Spawn a background task using the `run_command` tool to run `gh pr checks --watch` (with `BypassSandbox: true` since it requires network access). 
+2. **CRITICAL**: Do NOT use `&&`, `|`, or other complex shell syntax when running this command. Use clean, direct binary invocations so the user can use the "Always Allow" feature without being spammed with permission prompts.
+3. Because it's running in the background, you and the user can continue conversing. When the CI pipeline finishes, the task will automatically complete and you will receive a notification with the results.
+4. If the background task output shows that any checks failed, you MUST automatically investigate the failures (e.g., using `gh run list` and `gh run view <id> --log-failed`) and attempt to fix them.
+5. Do not ask for permission to fix CI failures. Proceed immediately to resolving the issue.
+
+This ensures you act as an adaptive, self-healing agent that takes full ownership of the PR lifecycle without bothering the user with sandbox permissions.

.claude/rules/planning-approval.md

@@ -22,3 +22,4 @@ When given a new issue or task, you **MUST NOT** begin modifying source code, up
 ## 3. Execution Phase
 * **STOP** and wait for the user to approve the strategy.
 * Only *after* explicit approval may you proceed to checkout a branch, edit files, bypass sandboxes for CI runs, and create pull requests.
+* **CRITICAL**: Once the user approves the plan (e.g., "approve and proceed"), you MUST execute the entire approved plan **autonomously**. Do not pause to ask for permission for individual steps (like modifying code, running tests, or committing). Only pause and ask the user if you encounter an unexpected failure or if the plan requires a major deviation.

.claude/rules/sandbox-permissions.md

@@ -0,0 +1,20 @@
+---
+description: "Rules for minimizing sandbox permission prompts"
+globs: "*"
+---
+# Sandbox Permission Minimization
+
+**CRITICAL INSTRUCTION: Avoid Permission Spam.**
+
+The Antigravity terminal sandbox includes an "Always Allow" feature that auto-approves commands based on a prefix match of the binary (e.g., `git`, `gh`, `python3`).
+
+However, complex shell syntax breaks this cache and forces the user to manually approve the command EVERY single time.
+
+**To avoid spamming the user with permission prompts, follow these rules for `run_command`:**
+1. **NEVER use chained commands** (`&&`, `||`, `;`) unless absolutely unavoidable. Run them as separate tool calls.
+2. **NEVER use pipes** (`|`). If you need to process output, save it to a file or process it in Python.
+3. **NEVER use command substitution** (`$(...)` or backticks).
+4. **Avoid inline environment variables** (`VAR=val cmd`). If you need them, use `RunPersistent=True` to create a terminal, `export` the variables in one call, and run the command in the next call.
+5. **Use direct binary invocations** (e.g., `.venv-zerodep/bin/python3 script.py`).
+
+By keeping commands clean and simple, you ensure the user's "Always Allow" selections are respected, vastly improving iteration speed.

.claude/skills/tree-sitter-accuracy-sweep/SKILL.md

@@ -337,3 +337,4 @@ the whole time.
 - Editing `~/.gemini/antigravity-cli/settings.json` needs a specific, in-the-moment
   `AskUserQuestion` approval each time new worktree paths are added -- a general earlier "go
   ahead" doesn't carry forward.
+- **The 15-Second Golden Master Trap:** `GalaxyScope` has a hardcoded 15-second `SIGALRM` timeout to prevent regex ReDoS on massive files. Because local sandbox CPUs are often slower than GitHub Actions runners, massive files (like C#'s `LanguageParser.cs` or TypeScript's `frames.ts`) may hit the 15s timeout locally but succeed on CI. This causes `update_golden_master.py` to generate truncated metrics locally (e.g., 0 function parameters). When CI runs, it parses the files correctly, compares them to your truncated local baseline, and fails with a mismatch. **To fix this:** temporarily increase `signal.alarm(15)` to `signal.alarm(60)` in `gitgalaxy/galaxyscope.py` before running `update_golden_master.py` locally, and revert it afterward. This guarantees the local baseline matches the CI runners' output.