Update

2026-09-06 17:11:25 -04:00
parent ee30af5599
commit 2bfb9de5c0
5 changed files with 2 additions and 152 deletions
@@ -1,27 +0,0 @@
- Prefer concise, readable code over clever one-liners
- No unnecessary comments — code should be self-documenting
- Docker-friendly: no hardcoded paths, use env vars for config
-
-<!-- codebase-memory-mcp:start -->
-# Codebase Knowledge Graph (codebase-memory-mcp)
-
-This project uses codebase-memory-mcp to maintain a knowledge graph of the codebase.
-ALWAYS prefer MCP graph tools over grep/glob/file-search for code discovery.
-
-## Priority Order
-1. `search_graph` — find functions, classes, routes, variables by pattern
-2. `trace_path` — trace who calls a function or what it calls
-3. `get_code_snippet` — read specific function/class source code
-4. `query_graph` — run Cypher queries for complex patterns
-5. `get_architecture` — high-level project summary
-
-## When to fall back to grep/glob
- Searching for string literals, error messages, config values
- Searching non-code files (Dockerfiles, shell scripts, configs)
- When MCP tools return insufficient results
-
-## Examples
- Find a handler: `search_graph(name_pattern=".*OrderHandler.*")`
- Who calls it: `trace_path(function_name="OrderHandler", direction="inbound")`
- Read source: `get_code_snippet(qualified_name="pkg/orders.OrderHandler")`
-<!-- codebase-memory-mcp:end -->
@@ -1,40 +0,0 @@
-{
-    "$schema": "https://opencode.ai/config.json",
-    "agent": {
-        "build": {
-            "model": "opencode-go/deepseek-v4-flash",
-            "temperature": 1.0,
-            "top_p": 0.95,
-            "permission": {
-                "skill": {
-                    "git-*": "allow"
-                }
-            }
-        },
-        "plan": {
-            "model": "kimi-for-coding/k3"
-        }
-    },
-    "mcp": {
-        "gitea-mcp": {
-            "enabled": true,
-            "type": "local",
-            "command": [
-                "gitea-mcp",
-                "-t",
-                "stdio",
-                "-H",
-                "https://gitea.itspm.cc",
-                "-T",
-                "82e8aeb9bcf9b26d1bad9167549f6532f968bcb0"
-            ]
-        },
-        "codebase-memory-mcp": {
-            "enabled": true,
-            "type": "local",
-            "command": [
-                "/home/pmcc/.local/bin/codebase-memory-mcp"
-            ]
-        }
-    }
-}
@@ -1,76 +0,0 @@
---
-name: git-commit
-description: Generate git commit messages using Conventional Commits specification
-license: MIT
---
-
-# Specification
-
-The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.
-
- Commits MUST be prefixed with a type, which consists of a noun, feat, fix, etc., followed by the OPTIONAL scope, OPTIONAL !, and REQUIRED terminal colon and space.
- The type feat MUST be used when a commit adds a new feature to your application or library.
- The type fix MUST be used when a commit represents a bug fix for your application.
- A scope MAY be provided after a type. A scope MUST consist of a noun describing a section of the codebase surrounded by parenthesis, e.g., fix(parser):
- A description MUST immediately follow the colon and space after the type/scope prefix. The description is a short summary of the code changes, e.g., fix: array parsing issue when multiple spaces were contained in string.
- A longer commit body MAY be provided after the short description, providing additional contextual information about the code changes. The body MUST begin one blank line after the description.
- A commit body is free-form and MAY consist of any number of newline separated paragraphs.
- One or more footers MAY be provided one blank line after the body. Each footer MUST consist of a word token, followed by either a :<space> or <space># separator, followed by a string value (this is inspired by the git trailer convention).
- A footer’s token MUST use - in place of whitespace characters, e.g., Acked-by (this helps differentiate the footer section from a multi-paragraph body). An exception is made for BREAKING CHANGE, which MAY also be used as a token.
- A footer’s value MAY contain spaces and newlines, and parsing MUST terminate when the next valid footer token/separator pair is observed.
- Breaking changes MUST be indicated in the type/scope prefix of a commit, or as an entry in the footer.
- If included as a footer, a breaking change MUST consist of the uppercase text BREAKING CHANGE, followed by a colon, space, and description, e.g., BREAKING CHANGE: environment variables now take precedence over config files.
- If included in the type/scope prefix, breaking changes MUST be indicated by a ! immediately before the :. If ! is used, BREAKING CHANGE: MAY be omitted from the footer section, and the commit description SHALL be used to describe the breaking change.
- Types other than feat and fix MAY be used in your commit messages, e.g., docs: update ref docs.
- The units of information that make up Conventional Commits MUST NOT be treated as case-sensitive by implementors, with the exception of BREAKING CHANGE which MUST be uppercase.
- BREAKING-CHANGE MUST be synonymous with BREAKING CHANGE, when used as a token in a footer.
-
-# Examples
-
-Commit message with description and breaking change footer
-```
-feat: allow provided config object to extend other configs
-
-BREAKING CHANGE: `extends` key in config file is now used for extending other config files
-```
-
-Commit message with ! to draw attention to breaking change
-```
-feat!: send an email to the customer when a product is shipped
-```
-
-Commit message with scope and ! to draw attention to breaking change
-```
-feat(api)!: send an email to the customer when a product is shipped
-```
-
-Commit message with both ! and BREAKING CHANGE footer
-```
-feat!: drop support for Node 6
-
-BREAKING CHANGE: use JavaScript features not available in Node 6.
-```
-
-Commit message with no body
-```
-docs: correct spelling of CHANGELOG
-```
-
-Commit message with scope
-```
-feat(lang): add Polish language
-```
-
-Commit message with multi-paragraph body and multiple footers
-```
-fix: prevent racing of requests
-
-Introduce a request id and a reference to latest request. Dismiss
-incoming responses other than from latest request.
-
-Remove timeouts which were used to mitigate the racing issue but are
-obsolete now.
-
-Reviewed-by: Z
-Refs: #123
-```
@@ -1,10 +1,7 @@
-{{ if eq .chezmoi.hostname "framework13pro" -}}
+{{ if eq .chezmoi.hostname "fw13pro" -}}
 output eDP-1 mode 2880x1920@120Hz
 {{- else if eq .chezmoi.hostname "flow" -}}
 output DP-1 mode 3840x2160@240Hz scale 1.5 pos 0 0 adaptive_sync on
 output DP-2 mode 2560x1440@240Hz scale 1.2 transform 90 pos 2560 -140 adaptive_sync off
 output * allow_tearing yes max_render_time off
-{{- else if eq .chezmoi.hostname "gata" -}}
-output DP-1 mode 2560x1440@144Hz position 0 0
-output HDMI-A-1 mode 2560x1440@75Hz transform 270 position -1440 -365
 {{- end }}
@@ -1,11 +1,7 @@
-{{- if eq .chezmoi.hostname "framework13pro" -}}
+{{- if eq .chezmoi.hostname "fw13pro" -}}
 [{{ template "bar-primary" (dict "out" "eDP-1" "ws" (list "1" "2" "3" "4")) }},
 {{ template "bar-secondary" . }}]
 {{- else if eq .chezmoi.hostname "flow" -}}
 [{{ template "bar-primary" (dict "out" "DP-1" "ws" (list "1" "2" "3" "4")) }},
 {{ template "bar-secondary" . }}]
-{{- else if eq .chezmoi.hostname "gata" -}}
-// TODO: confirm gata's primary output (run: swaymsg -t get_outputs)
-[{{ template "bar-primary" (dict "out" "DP-1" "ws" (list "1" "2" "3" "4")) }},
-{{ template "bar-secondary" . }}]
 {{- end }}