Update coding rules and CI configuration

- Added a new guideline to never suppress errors silently in coding rules.
- Introduced specifications for command files, including markdown format and kebab-case filenames.
- Updated Git workflow to require explicit user permission before pushing or merging changes.
- Adjusted Woodpecker CI configuration to trigger on push events.

Made-with: Cursor

.cursor/rules/coderule.mdc

@@ -9,6 +9,7 @@ alwaysApply: true
   - Logic specific to a platform, variant, or environment belongs in the class that owns that variant, not in the general coordinator. Passing a dependency through is preferable to leaking variant-specific concepts into shared code.
   - Only use static methods for pure, self-contained computations (constants, simple math, stateless lookups). If a static method involves resource access, side effects, OS interaction, or logic that varies across subclasses or environments — use an instance method or factory class instead. Before implementing a non-trivial static method, ask the user.
 - Generate concise code
+- Never suppress errors silently — no `2>/dev/null`, empty `catch` blocks, bare `except: pass`, or discarded error returns. These hide the information you need most when something breaks. If an error is truly safe to ignore, log it or comment why.
 - Do not put comments in the code, except in tests: every test must use the Arrange / Act / Assert pattern with language-appropriate comment syntax (`# Arrange` for Python, `// Arrange` for C#/Rust/JS/TS). Omit any section that is not needed (e.g. if there is no setup, skip Arrange; if act and assert are the same line, keep only Assert)
 - Do not put logs unless it is an exception, or was asked specifically
 - Do not put code annotations unless it was asked specifically