Sync .cursor from suite (autodev orchestrator + monorepo skills)

.cursor/rules/automation-scripts.mdc

@@ -6,5 +6,5 @@ alwaysApply: false
 
 # Automation Scripts
 
-- Automate everything that can be automated. If a dependency can be downloaded and installed, do it automatically — never require the user to manually download and set up prerequisites.
+- Automate repeatable setup steps in scripts. For dependencies with official package managers (apt, brew, pip, npm), automate installation. For binaries from external URLs, document the download but require user review before execution.
 - Use sensible defaults for paths and configuration (e.g. `/opt/` for system-wide tools). Allow overrides via environment variables for users who need non-standard locations.

.cursor/rules/dotnet.mdc

@@ -5,7 +5,7 @@ globs: ["**/*.cs", "**/*.csproj", "**/*.sln"]
 # .NET / C#
 
 - PascalCase for classes, methods, properties, namespaces; camelCase for locals and parameters; prefix interfaces with `I`
-- Use `async`/`await` for I/O-bound operations, do not suffix async methods with Async
+- Use `async`/`await` for I/O-bound operations; the `Async` suffix on method names is optional — follow the project's existing convention
 - Use dependency injection via constructor injection; register services in `Program.cs`
 - Use linq2db for small projects, EF Core with migrations for big ones; avoid raw SQL unless performance-critical; prevent N+1 with `.Include()` or projection
 - Use `Result<T, E>` pattern or custom error types over throwing exceptions for expected failures

.cursor/rules/quality-gates.mdc

@@ -4,7 +4,7 @@ alwaysApply: true
 ---
 # Quality Gates
 
-- After substantive code edits, run `ReadLints` on modified files and fix introduced errors
+- After any code edit that changes logic, adds/removes imports, or modifies function signatures, run `ReadLints` on modified files and fix introduced errors
 - Before committing, run the project's formatter if one exists (black, rustfmt, prettier, dotnet format)
 - Respect existing `.editorconfig`, `.prettierrc`, `pyproject.toml [tool.black]`, or `rustfmt.toml`
 - Do not commit code with Critical or High severity lint errors

.cursor/rules/techstackrule.mdc

@@ -4,6 +4,6 @@ alwaysApply: true
 ---
 # Tech Stack
 - Prefer Postgres database, but ask user
-- Depending on task, for backend prefer .Net or Python. Rust for performance-critical things.
+- For new backend projects: use .NET for structured enterprise/API services, Python for data/ML/scripting tasks, Rust for performance-critical components. For existing projects, use the language already established in that project.
 - For the frontend, use React with Tailwind css (or even plain css, if it is a simple project)
 - document api with OpenAPI

.cursor/rules/tracker.mdc

@@ -14,9 +14,12 @@ alwaysApply: true
 - Issue types: Epic, Story, Task, Bug, Subtask
 
 ## Tracker Availability Gate
-- If Jira MCP returns **Unauthorized**, **errored**, **connection refused**, or any non-success response: **STOP** tracker operations and notify the user.
-- The user must fix the Jira MCP connection before any further ticket creation/transition/query is attempted.
-- Do NOT silently create local-only tasks, skip Jira steps, or pretend the write succeeded. The tracker is the source of truth — if a status transition is lost, the team loses visibility.
+- If Jira MCP returns **Unauthorized**, **errored**, **connection refused**, or any non-success response: **STOP** tracker operations and notify the user via the Choose A/B/C/D format documented in `.cursor/skills/autodev/protocols.md`.
+- The user may choose to:
+  - **Retry authentication** — preferred; the tracker remains the source of truth.
+  - **Continue in `tracker: local` mode** — only when the user explicitly accepts this option. In that mode all tasks keep numeric prefixes and a `Tracker: pending` marker is written into each task header. The state file records `tracker: local`. The mode is NOT silent — the user has been asked and has acknowledged the trade-off.
+- Do NOT auto-fall-back to `tracker: local` without a user decision. Do not pretend a write succeeded. If the user is unreachable (e.g., non-interactive run), stop and wait.
+- When the tracker becomes available again, any `Tracker: pending` tasks should be synced — this is done at the start of the next `/autodev` invocation via the Leftovers Mechanism below.
 
 ## Leftovers Mechanism (non-user-input blockers only)
 
@@ -40,11 +43,11 @@ If a blocker of this kind appears, STOP and ASK — do not write to leftovers.
 
 ### Replay obligation
 
-At the start of every `/autopilot` invocation, and before any new tracker write in any skill, check `_docs/_process_leftovers/` for pending entries. For each entry:
+At the start of every `/autodev` invocation, and before any new tracker write in any skill, check `_docs/_process_leftovers/` for pending entries. For each entry:
 
 1. Attempt to replay the deferred write against the tracker
 2. If replay succeeds → delete the leftover entry
 3. If replay still fails → update the entry's timestamp and reason, continue
 4. If the blocker now requires user input (e.g., MCP still down after N retries) → surface to the user
 
-Autopilot must not progress past its own step 0 until all leftovers that CAN be replayed have been replayed.
+Autodev must not progress past its own step 0 until all leftovers that CAN be replayed have been replayed.