Migrate to chezmoi with per-host sway/waybar configs
- Restructure repo into chezmoi source layout (dot_ prefix) - Add .chezmoi.toml.tmpl mapping hostname to hosttype (laptop/desktop) - Template sway config.d fragments (outputs/inputs/binds) per host - Template waybar config.jsonc with shared bar/module definitions - Host-scope pulsemeeter (flow) and teams-for-linux (desktop hosts) via .chezmoiignore - Trim install.sh package lists to configured software + config deps - Remove stale kitty.conf.bak and untracked host fragments
This commit is contained in:
@@ -0,0 +1,27 @@
|
||||
- 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 -->
|
||||
@@ -0,0 +1,40 @@
|
||||
{
|
||||
"$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"
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
@@ -0,0 +1,76 @@
|
||||
---
|
||||
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
|
||||
```
|
||||
Reference in New Issue
Block a user