alex/dotfiles
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

initial commit

Browse Source
This commit is contained in:
alex
2026-03-08 14:37:55 +00:00
commit 4da672cbc7
62 changed files with 3460 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

24
.bashrc Normal file
View File

@@ -0,0 +1,24 @@
#
# ~/.bashrc
#
export HISTSIZE=10
# If not running interactively, don't do anything
[[ $- != *i* ]] && return
alias e="nvim"
alias n="nvim ."
alias ls='ls -la --color=auto'
alias grep='grep --color=auto'
PS1='[\u@\h \W]\$ '
export OPENCODE_ENABLE_EXA=1
export PATH="/home/alex/.bun/bin:$PATH"
alias c="opencode"
alias cc="opencode --continue"
alias ff="biome format --fix"
. "$HOME/.local/bin/env"

345
.config/hypr/hyprland.conf Normal file
View File

@@ -0,0 +1,345 @@
# #######################################################################################
# AUTOGENERATED HYPRLAND CONFIG.
# EDIT THIS CONFIG ACCORDING TO THE WIKI INSTRUCTIONS.
# #######################################################################################
# This is an example Hyprland config file.
# Refer to the wiki for more information.
# https://wiki.hypr.land/Configuring/
# Please note not all available settings / options are set here.
# For a full list, see the wiki
# You can split this configuration into multiple files
# Create your files separately and then link them to this file like this:
# source = ~/.config/hypr/myColors.conf
################
### MONITORS ###
################
# See https://wiki.hypr.land/Configuring/Monitors/
monitor=,preferred,auto,auto
###################
### MY PROGRAMS ###
###################
# See https://wiki.hypr.land/Configuring/Keywords/
# Set programs that you use
$terminal = kitty
$fileManager = thunar
$menu = rofi -show drun
#################
### AUTOSTART ###
#################
# Autostart necessary processes (like notifications daemons, status bars, etc.)
# Or execute your favorite apps at launch like this:
exec-once = waybar & nm-applet
exec-once = protonmail-bridge --no-window
exec-once = protonvpn-app
#############################
### ENVIRONMENT VARIABLES ###
#############################
# See https://wiki.hypr.land/Configuring/Environment-variables/
env = XCURSOR_SIZE,24
env = HYPRCURSOR_SIZE,24
###################
### PERMISSIONS ###
###################
# See https://wiki.hypr.land/Configuring/Permissions/
# Please note permission changes here require a Hyprland restart and are not applied on-the-fly
# for security reasons
# ecosystem {
# enforce_permissions = 1
# }
# permission = /usr/(bin|local/bin)/grim, screencopy, allow
# permission = /usr/(lib|libexec|lib64)/xdg-desktop-portal-hyprland, screencopy, allow
# permission = /usr/(bin|local/bin)/hyprpm, plugin, allow
#####################
### LOOK AND FEEL ###
#####################
# Refer to https://wiki.hypr.land/Configuring/Variables/
# https://wiki.hypr.land/Configuring/Variables/#general
general {
gaps_in = 0
gaps_out = 0
border_size = 1
# https://wiki.hypr.land/Configuring/Variables/#variable-types for info about colors
# Catppuccin Mocha: lavender (#b4befe) to mauve (#cba6f7) gradient
col.active_border = rgba(b4befeee) rgba(cba6f7ee) 45deg
# Catppuccin Mocha: surface0 (#313244)
col.inactive_border = rgba(313244aa)
# Set to true enable resizing windows by clicking and dragging on borders and gaps
resize_on_border = false
# Please see https://wiki.hypr.land/Configuring/Tearing/ before you turn this on
allow_tearing = false
layout = dwindle
}
# https://wiki.hypr.land/Configuring/Variables/#decoration
decoration {
rounding = 10
rounding_power = 2
# Change transparency of focused and unfocused windows
active_opacity = 1.0
inactive_opacity = 1.0
shadow {
enabled = true
range = 4
render_power = 3
# Catppuccin Mocha: crust (#11111b)
color = rgba(11111bee)
}
# https://wiki.hypr.land/Configuring/Variables/#blur
blur {
enabled = true
size = 3
passes = 1
vibrancy = 0.1696
}
}
# https://wiki.hypr.land/Configuring/Variables/#animations
animations {
enabled = no
}
# Ref https://wiki.hypr.land/Configuring/Workspace-Rules/
# "Smart gaps" / "No gaps when only"
# uncomment all if you wish to use that.
# workspace = w[tv1], gapsout:0, gapsin:0
# workspace = f[1], gapsout:0, gapsin:0
# windowrule {
# name = no-gaps-wtv1
# match:float = false
# match:workspace = w[tv1]
#
# border_size = 0
# rounding = 0
# }
#
# windowrule {
# name = no-gaps-f1
# match:float = false
# match:workspace = f[1]
#
# border_size = 0
# rounding = 0
# }
# See https://wiki.hypr.land/Configuring/Dwindle-Layout/ for more
dwindle {
pseudotile = true # Master switch for pseudotiling. Enabling is bound to mainMod + P in the keybinds section below
preserve_split = true # You probably want this
}
# See https://wiki.hypr.land/Configuring/Master-Layout/ for more
master {
new_status = master
}
# https://wiki.hypr.land/Configuring/Variables/#misc
misc {
force_default_wallpaper = 0 # Set to 0 or 1 to disable the anime mascot wallpapers
disable_hyprland_logo = true # If true disables the random hyprland logo / anime girl background. :(
}
#############
### INPUT ###
#############
# https://wiki.hypr.land/Configuring/Variables/#input
input {
kb_layout = us, br
kb_variant =
kb_model =
kb_options = caps:super, grp:alts_toggle
kb_rules =
follow_mouse = 1
sensitivity = 0 # -1.0 - 1.0, 0 means no modification.
touchpad {
natural_scroll = false
}
}
# See https://wiki.hypr.land/Configuring/Gestures
gesture = 3, horizontal, workspace
# Example per-device config
# See https://wiki.hypr.land/Configuring/Keywords/#per-device-input-configs for more
device {
name = epic-mouse-v1
sensitivity = -0.5
}
###################
### KEYBINDINGS ###
###################
# See https://wiki.hypr.land/Configuring/Keywords/
$mainMod = SUPER # Sets "Windows" key as main modifier
# Example binds, see https://wiki.hypr.land/Configuring/Binds/ for more
bind = $mainMod, return, exec, $terminal
bind = $mainMod, q, killactive,
bind = $mainMod, E, exec, $fileManager
bind = $mainMod, space, exec, $menu
bind = $mainMod, f, fullscreen
bind = $mainMod SHIFT, s, togglesplit
bind = $mainMod, R, submap, resize
submap = resize
binde = , l, resizeactive, 30 0
binde = , h, resizeactive, -30 0
binde = , k, resizeactive, 0 -30
binde = , j, resizeactive, 0 30
bind = , escape, submap, reset
submap = reset
# Application shortcuts
bind = $mainMod, b, exec, brave
bind = $mainMod SHIFT, b, exec, brave --incognito
bind = $mainMod, m, exec, thunderbird
bind = $mainMod, v, exec, protonvpn-app
# Lock screen
bind = $mainMod, c, exec, hyprlock
# Screenshot
bind = , Print, exec, hyprshot -m region
# Move focus with mainMod + arrow keys
bind = $mainMod, h, movefocus, l
bind = $mainMod, l, movefocus, r
bind = $mainMod, k, movefocus, u
bind = $mainMod, j, movefocus, d
bind = $mainMod SHIFT, h, movewindow, l
bind = $mainMod SHIFT, l, movewindow, r
bind = $mainMod SHIFT, k, movewindow, u
bind = $mainMod SHIFT, j, movewindow, d
# Switch workspaces with mainMod + [0-9]
bind = $mainMod, 1, workspace, 1
bind = $mainMod, 2, workspace, 2
bind = $mainMod, 3, workspace, 3
bind = $mainMod, 4, workspace, 4
bind = $mainMod, 5, workspace, 5
bind = $mainMod, 6, workspace, 6
bind = $mainMod, 7, workspace, 7
bind = $mainMod, 8, workspace, 8
bind = $mainMod, 9, workspace, 9
bind = $mainMod, 0, workspace, 10
# Move active window to a workspace with mainMod + SHIFT + [0-9]
bind = $mainMod SHIFT, 1, movetoworkspace, 1
bind = $mainMod SHIFT, 2, movetoworkspace, 2
bind = $mainMod SHIFT, 3, movetoworkspace, 3
bind = $mainMod SHIFT, 4, movetoworkspace, 4
bind = $mainMod SHIFT, 5, movetoworkspace, 5
bind = $mainMod SHIFT, 6, movetoworkspace, 6
bind = $mainMod SHIFT, 7, movetoworkspace, 7
bind = $mainMod SHIFT, 8, movetoworkspace, 8
bind = $mainMod SHIFT, 9, movetoworkspace, 9
bind = $mainMod SHIFT, 0, movetoworkspace, 10
# Example special workspace (scratchpad)
bind = $mainMod, S, togglespecialworkspace, magic
bind = $mainMod SHIFT, S, movetoworkspace, special:magic
# Scroll through existing workspaces with mainMod + scroll
bind = $mainMod, mouse_down, workspace, e+1
bind = $mainMod, mouse_up, workspace, e-1
# Move/resize windows with mainMod + LMB/RMB and dragging
bindm = $mainMod, mouse:272, movewindow
bindm = $mainMod, mouse:273, resizewindow
# Laptop multimedia keys for volume and LCD brightness
bindel = ,XF86AudioRaiseVolume, exec, wpctl set-volume -l 1 @DEFAULT_AUDIO_SINK@ 5%+
bindel = ,XF86AudioLowerVolume, exec, wpctl set-volume @DEFAULT_AUDIO_SINK@ 5%-
bindel = ,XF86AudioMute, exec, wpctl set-mute @DEFAULT_AUDIO_SINK@ toggle
bindel = ,XF86AudioMicMute, exec, wpctl set-mute @DEFAULT_AUDIO_SOURCE@ toggle
bindel = ,XF86MonBrightnessUp, exec, brightnessctl -e4 -n2 set 5%+
bindel = ,XF86MonBrightnessDown, exec, brightnessctl -e4 -n2 set 5%-
# Requires playerctl
bindl = , XF86AudioNext, exec, playerctl next
bindl = , XF86AudioPause, exec, playerctl play-pause
bindl = , XF86AudioPlay, exec, playerctl play-pause
bindl = , XF86AudioPrev, exec, playerctl previous
##############################
### WINDOWS AND WORKSPACES ###
##############################
# See https://wiki.hypr.land/Configuring/Window-Rules/ for more
# See https://wiki.hypr.land/Configuring/Workspace-Rules/ for workspace rules
# Example windowrules that are useful
windowrule {
# Ignore maximize requests from all apps. You'll probably like this.
name = suppress-maximize-events
match:class = .*
suppress_event = maximize
}
windowrule {
# Fix some dragging issues with XWayland
name = fix-xwayland-drags
match:class = ^$
match:title = ^$
match:xwayland = true
match:float = true
match:fullscreen = false
match:pin = false
no_focus = true
}
# Hyprland-run windowrule
windowrule {
name = move-hyprland-run
match:class = hyprland-run
move = 20 monitor_h-120
float = no
}

89
.config/hypr/hyprlock.conf Normal file
View File

@@ -0,0 +1,89 @@
# Hyprlock config with Catppuccin Mocha theme
# Background
background {
monitor =
path = ~/.config/wallpapers/lock.png # Fallback to solid color if no image
color = rgba(30, 30, 46, 1.0) # Catppuccin Mocha base (#1e1e2e)
# Blur
blur_passes = 2
blur_size = 7
noise = 0.0117
contrast = 0.8916
brightness = 0.8172
vibrancy = 0.1696
vibrancy_darkness = 0.0
}
# Time
label {
monitor =
text = cmd[update:1000] echo "$(date +"%H:%M")"
color = rgba(205, 214, 244, 1.0) # Catppuccin Mocha text (#cdd6f4)
font_size = 120
font_family = JetBrainsMono Nerd Font Bold
position = 0, 200
halign = center
valign = center
}
# Date
label {
monitor =
text = cmd[update:1000] echo "$(date +"%A, %B %d")"
color = rgba(180, 190, 254, 1.0) # Catppuccin Mocha lavender (#b4befe)
font_size = 30
font_family = JetBrainsMono Nerd Font
position = 0, 80
halign = center
valign = center
}
# Password input
input-field {
monitor =
size = 300, 50
outline_thickness = 2
dots_size = 0.3
dots_spacing = 0.15
dots_center = true
dots_rounding = 2
outer_color = rgba(180, 190, 254, 1.0) # Lavender
inner_color = rgba(49, 50, 68, 1.0) # Surface0
font_color = rgba(205, 214, 244, 1.0) # Text
fade_on_empty = false
placeholder_text = <i>Enter password...</i>
hide_input = false
check_color = rgba(166, 227, 161, 1.0) # Green
fail_color = rgba(243, 139, 168, 1.0) # Red
fail_text = <i>$FAIL <b>($ATTEMPTS)</b></i>
capslock_color = rgba(249, 226, 175, 1.0) # Yellow
position = 0, -80
halign = center
valign = center
}
# Lock icon
label {
monitor =
text =
color = rgba(203, 166, 247, 1.0) # Catppuccin Mocha mauve (#cba6f7)
font_size = 40
font_family = Font Awesome 6 Free
position = 0, -150
halign = center
valign = center
}
# User label
label {
monitor =
text = $USER
color = rgba(205, 214, 244, 1.0) # Text
font_size = 20
font_family = JetBrainsMono Nerd Font
position = 0, -180
halign = center
valign = center
}

72
.config/kitty/kitty.conf Normal file
View File

@@ -0,0 +1,72 @@
# Catppuccin Mocha theme for Kitty
# The basic colors
foreground #cdd6f4
background #1e1e2e
selection_foreground #1e1e2e
selection_background #f5e0dc
# Cursor colors
cursor #f5e0dc
cursor_text_color #1e1e2e
# URL underline color when hovering with mouse
url_color #f5e0dc
# Kitty window border colors
active_border_color #b4befe
inactive_border_color #6c7086
bell_border_color #f9e2af
# OS Window titlebar colors
wayland_titlebar_color #1e1e2e
macos_titlebar_color #1e1e2e
# Tab bar colors
active_tab_foreground #11111b
active_tab_background #cba6f7
inactive_tab_foreground #cdd6f4
inactive_tab_background #181825
tab_bar_background #11111b
# Colors for marks (marked text in the terminal)
mark1_foreground #1e1e2e
mark1_background #b4befe
mark2_foreground #1e1e2e
mark2_background #cba6f7
mark3_foreground #1e1e2e
mark3_background #74c7ec
# The 16 terminal colors
# black
color0 #45475a
color8 #585b70
# red
color1 #f38ba8
color9 #f38ba8
# green
color2 #a6e3a1
color10 #a6e3a1
# yellow
color3 #f9e2af
color11 #f9e2af
# blue
color4 #89b4fa
color12 #89b4fa
# magenta
color5 #f5c2e7
color13 #f5c2e7
# cyan
color6 #94e2d5
color14 #94e2d5
# white
color7 #bac2de
color15 #a6adc8

31
.config/nvim/init.lua Normal file
View File

@@ -0,0 +1,31 @@
vim.g.mapleader = " "
local lazypath = vim.fn.stdpath("data") .. "/lazy/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
vim.fn.system({
"git",
"clone",
"--filter=blob:none",
"https://github.com/folke/lazy.nvim.git",
"--branch=stable",
lazypath,
})
end
vim.opt.rtp:prepend(lazypath)
require("lazy").setup({
{ import = "plugins" },
})
vim.keymap.set("n", "<leader>e", vim.cmd.Ex)
vim.keymap.set("n", "<leader>ww", vim.cmd.w)
vim.opt.number = true
vim.opt.relativenumber = true
vim.opt.wrap = false
local builtin = require("telescope.builtin")
vim.keymap.set("n", "<leader>ff", builtin.find_files, { desc = "Telescope find files" })
vim.keymap.set("n", "<leader>fg", builtin.live_grep, { desc = "Telescope live grep" })
vim.keymap.set("n", "<leader>fb", builtin.buffers, { desc = "Telescope buffers" })
vim.keymap.set("n", "<leader>fh", builtin.help_tags, { desc = "Telescope help tags" })

24
.config/nvim/lazy-lock.json Normal file
View File

@@ -0,0 +1,24 @@
{
"LuaSnip": { "branch": "master", "commit": "dae4f5aaa3574bd0c2b9dd20fb9542a02c10471c" },
"catppuccin": { "branch": "main", "commit": "c4d475e4b5684747cde9b3f849186af7837d4397" },
"cmp-buffer": { "branch": "main", "commit": "b74fab3656eea9de20a9b8116afa3cfc4ec09657" },
"cmp-nvim-lsp": { "branch": "main", "commit": "cbc7b02bb99fae35cb42f514762b89b5126651ef" },
"cmp-path": { "branch": "main", "commit": "c642487086dbd9a93160e1679a1327be111cbc25" },
"cmp_luasnip": { "branch": "master", "commit": "98d9cb5c2c38532bd9bdb481067b20fea8f32e90" },
"conform.nvim": { "branch": "master", "commit": "40dcec5555f960b0a04340d76eabdf4efe78599d" },
"friendly-snippets": { "branch": "main", "commit": "6cd7280adead7f586db6fccbd15d2cac7e2188b9" },
"lazy.nvim": { "branch": "main", "commit": "306a05526ada86a7b30af95c5cc81ffba93fef97" },
"lazydev.nvim": { "branch": "main", "commit": "5231c62aa83c2f8dc8e7ba957aa77098cda1257d" },
"lspkind-nvim": { "branch": "master", "commit": "c7274c48137396526b59d86232eabcdc7fed8a32" },
"mason-lspconfig.nvim": { "branch": "main", "commit": "a324581a3c83fdacdb9804b79de1cbe00ce18550" },
"mason-null-ls.nvim": { "branch": "main", "commit": "8e7806acaa87fae64f0bfde25bb4b87c18bd19b4" },
"mason.nvim": { "branch": "main", "commit": "44d1e90e1f66e077268191e3ee9d2ac97cc18e65" },
"none-ls.nvim": { "branch": "main", "commit": "f61f46ded0ca9edce7a09b674f8e162d10921426" },
"nvim-cmp": { "branch": "main", "commit": "da88697d7f45d16852c6b2769dc52387d1ddc45f" },
"nvim-lspconfig": { "branch": "master", "commit": "ead0f5f342d8d323441e7d4b88f0fc436a81ad5f" },
"nvim-treesitter": { "branch": "main", "commit": "544320a9cf5d6bf539ec1cc54d393064015670c4" },
"opencode.nvim": { "branch": "main", "commit": "7cae6b64cb2fe41bb515d9eec6e0da2494656706" },
"plenary.nvim": { "branch": "master", "commit": "b9fd5226c2f76c951fc8ed5923d85e4de065e509" },
"telescope-fzf-native.nvim": { "branch": "main", "commit": "6fea601bd2b694c6f2ae08a6c6fab14930c60e2c" },
"telescope.nvim": { "branch": "master", "commit": "3333a52ff548ba0a68af6d8da1e54f9cd96e9179" }
}

69
.config/nvim/lua/plugins/cmp.lua Normal file
View File

@@ -0,0 +1,69 @@
-- Autocompletion engine with LSP, snippet, buffer, and path sources.
-- Keymaps: Tab/S-Tab (navigate), Enter (confirm), Ctrl-Space (trigger), Esc (dismiss).
-- See README.md "Autocomplete" section for full usage details.
return {
"hrsh7th/nvim-cmp",
dependencies = {
"hrsh7th/cmp-nvim-lsp", -- LSP completion source
"hrsh7th/cmp-buffer", -- Buffer word completion source
"hrsh7th/cmp-path", -- Filesystem path completion source
"saadparwaiz1/cmp_luasnip", -- Snippet completion source (bridges LuaSnip)
"L3MON4D3/LuaSnip", -- Snippet engine
"onsails/lspkind-nvim", -- Completion menu icons
},
config = function()
local cmp = require("cmp")
local luasnip = require("luasnip")
local lspkind = require("lspkind")
cmp.setup({
snippet = {
expand = function(args)
luasnip.lsp_expand(args.body)
end,
},
mapping = cmp.mapping.preset.insert({
["<Tab>"] = cmp.mapping.select_next_item({ behavior = cmp.SelectBehavior.Select }),
["<S-Tab>"] = cmp.mapping.select_prev_item({ behavior = cmp.SelectBehavior.Select }),
["<CR>"] = cmp.mapping.confirm({ select = true }),
["<C-Space>"] = cmp.mapping.complete(),
["<Esc>"] = cmp.mapping.abort(),
}),
sources = cmp.config.sources({
{ name = "nvim_lsp" },
{ name = "luasnip" },
{
name = "buffer",
keyword_length = 2,
option = {
get_bufnrs = function()
local bufs = {}
for _, buf in ipairs(vim.api.nvim_list_bufs()) do
if vim.api.nvim_buf_is_loaded(buf) then
bufs[#bufs + 1] = buf
end
end
return bufs
end,
},
},
{ name = "path" },
}),
formatting = {
format = lspkind.cmp_format({
mode = "symbol_text",
menu = {
nvim_lsp = "[LSP]",
luasnip = "[Snippet]",
buffer = "[Buffer]",
path = "[Path]",
},
}),
},
window = {
documentation = cmp.config.window.bordered(),
},
})
end,
}

11
.config/nvim/lua/plugins/colorscheme.lua Normal file
View File

@@ -0,0 +1,11 @@
return {
"catppuccin/nvim",
name = "catppuccin",
priority = 1000,
config = function()
require("catppuccin").setup({
flavour = "mocha",
})
vim.cmd.colorscheme("catppuccin")
end,
}

33
.config/nvim/lua/plugins/conform.lua Normal file
View File

@@ -0,0 +1,33 @@
return {
"stevearc/conform.nvim",
event = { "BufWritePre" },
cmd = { "ConformInfo" },
opts = {
formatters_by_ft = {
lua = { "stylua" },
javascript = { "prettier" },
typescript = { "prettier" },
javascriptreact = { "prettier" },
typescriptreact = { "prettier" },
json = { "prettier" },
yaml = { "prettier" },
markdown = { "prettier" },
python = { "ruff_format" },
go = { "gofmt" },
},
format_on_save = {
timeout_ms = 500,
lsp_fallback = true,
},
},
keys = {
{
"<leader>f",
function()
require("conform").format({ async = true, lsp_fallback = true })
end,
mode = "",
desc = "Format buffer",
},
},
}

10
.config/nvim/lua/plugins/lazydev.lua Normal file
View File

@@ -0,0 +1,10 @@
return {
"folke/lazydev.nvim",
ft = "lua",
opts = {
library = {
-- Load luvit types when using `vim.uv`
{ path = "${3rd}/luv/library", words = { "vim%.uv" } },
},
},
}

16
.config/nvim/lua/plugins/lspconfig.lua Normal file
View File

@@ -0,0 +1,16 @@
return {
"neovim/nvim-lspconfig",
config = function()
vim.diagnostic.config({
virtual_text = true,
signs = true,
update_in_insert = false,
underline = true,
severity_sort = true,
float = {
border = "rounded",
source = "always",
},
})
end,
}

11
.config/nvim/lua/plugins/luasnip.lua Normal file
View File

@@ -0,0 +1,11 @@
-- Snippet engine with pre-built VS Code-style snippets from friendly-snippets.
-- Snippets are lazy-loaded per filetype. Used by nvim-cmp as a completion source.
return {
"L3MON4D3/LuaSnip",
dependencies = {
"rafamadriz/friendly-snippets", -- Community-maintained snippet collection
},
config = function()
require("luasnip.loaders.from_vscode").lazy_load()
end,
}

20
.config/nvim/lua/plugins/mason-lspconfig.lua Normal file
View File

@@ -0,0 +1,20 @@
-- Bridges Mason and lspconfig: auto-installs and enables language servers.
-- Injects nvim-cmp capabilities globally so all LSP servers support enhanced completions.
return {
"williamboman/mason-lspconfig.nvim",
dependencies = {
"williamboman/mason.nvim",
"neovim/nvim-lspconfig",
"hrsh7th/cmp-nvim-lsp", -- Required for completion capabilities
},
config = function()
local capabilities = require("cmp_nvim_lsp").default_capabilities()
vim.lsp.config("*", {
capabilities = capabilities,
})
require("mason-lspconfig").setup({
automatic_installation = true,
automatic_enable = true,
})
end,
}

13
.config/nvim/lua/plugins/mason-null-ls.lua Normal file
View File

@@ -0,0 +1,13 @@
return {
"jay-babu/mason-null-ls.nvim",
dependencies = {
"williamboman/mason.nvim",
"nvimtools/none-ls.nvim",
},
config = function()
require("mason-null-ls").setup({
automatic_installation = true,
handlers = {},
})
end,
}

4
.config/nvim/lua/plugins/mason.lua Normal file
View File

@@ -0,0 +1,4 @@
return {
"williamboman/mason.nvim",
config = true,
}

10
.config/nvim/lua/plugins/none-ls.lua Normal file
View File

@@ -0,0 +1,10 @@
return {
"nvimtools/none-ls.nvim",
dependencies = { "nvim-lua/plenary.nvim" },
config = function()
local null_ls = require("null-ls")
null_ls.setup({
sources = {},
})
end,
}

66
.config/nvim/lua/plugins/opencode.lua Normal file
View File

@@ -0,0 +1,66 @@
return {
"nickjvandyke/opencode.nvim",
version = "*", -- Latest stable release
dependencies = {
{
-- `snacks.nvim` integration is recommended, but optional
---@module "snacks" <- Loads `snacks.nvim` types for configuration intellisense
"folke/snacks.nvim",
optional = true,
opts = {
input = {}, -- Enhances `ask()`
picker = { -- Enhances `select()`
actions = {
opencode_send = function(...)
return require("opencode").snacks_picker_send(...)
end,
},
win = {
input = {
keys = {
["<a-a>"] = { "opencode_send", mode = { "n", "i" } },
},
},
},
},
},
},
},
config = function()
---@type opencode.Opts
vim.g.opencode_opts = {
-- Your configuration, if any; goto definition on the type or field for details
}
vim.o.autoread = true -- Required for `opts.events.reload`
-- Recommended/example keymaps
vim.keymap.set({ "n", "x" }, "<C-a>", function()
require("opencode").ask("@this: ", { submit = true })
end, { desc = "Ask opencode…" })
vim.keymap.set({ "n", "x" }, "<C-x>", function()
require("opencode").select()
end, { desc = "Execute opencode action…" })
vim.keymap.set({ "n", "t" }, "<C-.>", function()
require("opencode").toggle()
end, { desc = "Toggle opencode" })
vim.keymap.set({ "n", "x" }, "go", function()
return require("opencode").operator("@this ")
end, { desc = "Add range to opencode", expr = true })
vim.keymap.set("n", "goo", function()
return require("opencode").operator("@this ") .. "_"
end, { desc = "Add line to opencode", expr = true })
vim.keymap.set("n", "<S-C-u>", function()
require("opencode").command("session.half.page.up")
end, { desc = "Scroll opencode up" })
vim.keymap.set("n", "<S-C-d>", function()
require("opencode").command("session.half.page.down")
end, { desc = "Scroll opencode down" })
-- You may want these if you use the opinionated `<C-a>` and `<C-x>` keymaps above — otherwise consider `<leader>o…` (and remove terminal mode from the `toggle` keymap)
vim.keymap.set("n", "+", "<C-a>", { desc = "Increment under cursor", noremap = true })
vim.keymap.set("n", "-", "<C-x>", { desc = "Decrement under cursor", noremap = true })
end,
}

9
.config/nvim/lua/plugins/telescope.lua Normal file
View File

@@ -0,0 +1,9 @@
return {
"nvim-telescope/telescope.nvim",
version = "*",
dependencies = {
"nvim-lua/plenary.nvim",
-- optional but recommended
{ "nvim-telescope/telescope-fzf-native.nvim", build = "make" },
},
}

5
.config/nvim/lua/plugins/treesitter.lua Normal file
View File

@@ -0,0 +1,5 @@
return {
"nvim-treesitter/nvim-treesitter",
lazy = false,
build = ":TSUpdate",
}

BIN
.config/opencode/.megamemory/knowledge.db Normal file
View File

Binary file not shown.

65
.config/opencode/AGENTS.md Normal file
View File

@@ -0,0 +1,65 @@
## Project Knowledge Graph
You have access to a project knowledge graph via the `megamemory` MCP server and skill tool. You have no implicit memory of this project between sessions, so this graph is your only continuity for concepts, architecture, decisions, and relationships.
**Workflow: understand → work → update**
1. **Session start:** You must call `megamemory` with action `overview` (or `megamemory:list_roots` directly) before you begin work.
2. **Before each task:** You must call `megamemory` with action `query` (or `megamemory:understand` directly) before reading source files for project understanding.
3. **After each task:** You must call `megamemory` with action `record` to create/update/link concepts for what you built.
Be specific in summaries: include parameter names, defaults, file locations, and rationale. Keep concepts max 3 levels deep.
**Recording discipline:** Only record outcomes, decisions, and discoveries — never phase transitions, status changes, or ceremony checkpoints. If a concept would only say "we started phase X", don't create it. Megamemory exists to preserve *knowledge*, not to log *activity*.
**Query discipline:**
- Use `top_k=3` for `megamemory:understand` calls unless you have a specific reason to retrieve more. Large result sets bloat context without proportional value.
- **Skip `understand` when the graph has no relevant content.** If `list_roots` already showed no concepts in the relevant domain, do not call `understand` with rephrased queries hoping for different results.
- **Never re-query concepts you just created.** After calling `create_concept`, you already know the content — do not immediately call `understand` to retrieve it.
- Treat megamemory as a **tool**, not a ritual. Every query should have a specific information need; if you cannot articulate what you expect to find, skip the query.
**Linking is required.** When creating or updating concepts, always create edges (`megamemory:link`) to related existing concepts. A concept with no edges is a dead end — always ask: *"What existing concept does this depend on, implement, or connect to?"* and link accordingly.
## Session Continuity
- Treat megamemory as the persistent tracking system for work across sessions.
- At session start, identify prior in-progress work items and pending decisions before doing new implementation.
- After implementation, record what changed, why it changed, and what remains next.
## Clarification Rule
- If requirements are genuinely unclear, materially ambiguous, or have multiple valid interpretations that would lead to **materially different implementations**, use the `question` tool to clarify before committing to an implementation path.
- **Do not ask for clarification when the user's intent is obvious.** If the user explicitly states what they want (e.g., "update X and also update Y"), do not ask "should I do both?" — proceed with the stated request.
- Implementation-level decisions (naming, file organization, approach) are the agent's job, not the user's. Only escalate decisions that affect **user-visible behavior or scope**.
## Agent Roster
| Agent | Role | Model |
|---|---|---|
| `lead` | Primary orchestrator that decomposes work, delegates, and synthesizes outcomes. | `github-copilot/claude-opus-4` (global default) |
| `coder` | Implementation-focused coding agent for reliable code changes. | `github-copilot/gpt-5.3-codex` |
| `reviewer` | Read-only quality gate for correctness and security review. | `github-copilot/claude-opus-4.6` |
| `tester` | Validation agent for standard + adversarial testing and Playwright UI checks. | `github-copilot/claude-sonnet-4.6` |
| `explorer` | Fast read-only codebase mapper for impact surface and dependencies. | `github-copilot/claude-sonnet-4.6` |
| `researcher` | Deep technical investigator across code, docs, and external references. | `github-copilot/claude-opus-4.6` |
| `librarian` | Documentation coverage and accuracy specialist. | `github-copilot/claude-opus-4.6` |
| `critic` | Pre-implementation gate and blocker sounding board. | `github-copilot/claude-opus-4.6` |
| `sme` | Subject-matter expert for domain-specific consultation. | `github-copilot/claude-opus-4.6` |
| `designer` | UI/UX specialist for interaction and visual guidance. | `github-copilot/claude-sonnet-4.6` |
## Parallelization
- **Always parallelize independent work.** Any tool calls that do not depend on each other's output must be issued in the same message as parallel calls — never sequentially. This applies to bash commands, file reads, subagent delegations, and megamemory queries alike.
- Before issuing a sequence of calls, ask: *"Does call B require the result of call A?"* If not, send them together.
## Human Checkpoint Triggers
When implementing features, the Lead must stop and request explicit user approval before dispatching coder work in these situations:
1. **Security-sensitive design**: Any feature involving encryption, auth flows, secret storage, token management, or permission model changes.
2. **Architectural ambiguity**: Multiple valid approaches with materially different tradeoffs that aren't resolvable from codebase conventions alone.
3. **Vision-dependent features**: Features where the user's intended UX or behavior model isn't fully specified by the request.
4. **New external dependencies**: Adding a service, SDK, or infrastructure component not already in the project.
5. **Data model changes with migration impact**: Schema changes affecting existing production data.
The checkpoint must present the specific decision, 2-3 concrete options with tradeoffs, a recommendation, and a safe default. Implementation-level decisions (naming, file organization, code patterns) are NOT checkpoints — only user-visible behavior and architectural choices qualify.

81
.config/opencode/agents/coder.md Normal file
View File

@@ -0,0 +1,81 @@
---
description: Implementation-focused coding agent for reliable code changes
mode: subagent
model: github-copilot/gpt-5.3-codex
temperature: 0.2
permission:
webfetch: deny
websearch: deny
codesearch: deny
---
You are the Coder subagent.
Purpose:
- Implement requested changes with clear, maintainable, convention-aligned code.
Pipeline position:
- You are step 1 of the quality pipeline: implement first, then hand off to lead for reviewer → tester.
- Do not treat your own implementation pass as final sign-off.
Operating rules:
1. Query megamemory with `megamemory:understand` (`top_k=3`) when relevant concepts likely exist; skip when `list_roots` already showed no relevant concepts in this domain this session; never re-query concepts you just created.
2. Follow existing project conventions and keep edits minimal and focused.
3. If requirements are materially ambiguous, use the `question` tool before coding.
4. Do not browse the web; rely on local context and provided tooling.
5. Scope discipline: only change what is needed for the requested outcome.
6. Do not refactor unrelated code or add unrequested features.
Scope rejection (hard rule):
- **If the delegation prompt asks you to implement more than one independent feature, return `BLOCKED` immediately.** Do not attempt multi-feature implementation. Respond with:
```
STATUS: BLOCKED
REASON: Delegation contains multiple independent features. Each feature must be a separate coder invocation.
FEATURES DETECTED: <list the distinct features>
```
- Two changes are "independent features" if they could be shipped separately, touch different functional areas, or solve different user problems.
- Two changes are a "single feature" if they are tightly coupled: shared state, same UI flow, or one is meaningless without the other (e.g., "add API endpoint" + "add frontend call to that endpoint" for the same feature).
- When in doubt, ask via `question` tool rather than proceeding with a multi-feature prompt.
7. **Use discovered values.** When the delegation prompt includes specific values discovered by explorer or researcher (i18n keys, file paths, API signatures, component names, existing patterns), use those exact values. Do not substitute your own guesses for discovered facts.
8. **Validate imports and references.** Verify every new/changed import path and symbol exists and resolves. If a new dependency is required, include the appropriate manifest update.
9. **Validate types and interfaces.** Verify changed signatures/contracts align with call sites and expected types.
10. **Discover local conventions first.** Before implementing in an area, inspect 2-3 nearby files and mirror naming, error handling, and pattern conventions.
11. **Megamemory recording discipline.** Record only structural discoveries (new module/pattern/contract) or implementation decisions, link them to the active task concept, and never record ceremony entries like "started/completed implementation".
Self-check before returning:
- Re-read changed files to confirm behavior matches acceptance criteria.
- Verify imports and references are still valid.
- Explicitly list assumptions (especially types, APIs, edge cases).
- **If retrying after reviewer/tester feedback**: verify each specific issue is addressed. Do not return without mapping every feedback item to a code change.
- **If known issues exist** (e.g., from the task description or prior discussion): verify they are handled before returning.
Retry protocol (after pipeline rejection):
- If reviewer returns `CHANGES-REQUESTED` or tester returns `FAIL`, address **all** noted issues.
- Map each feedback item to a concrete code change in your response.
- Keep retry awareness explicit (lead tracks retry count; after 3 rejections lead may simplify scope).
Quality bar:
- Prefer correctness and readability over cleverness.
- Keep changes scoped to the requested outcome.
- Note assumptions and any follow-up validation needed.
Return format (always):
```text
STATUS: <DONE|BLOCKED|PARTIAL>
CHANGES: <list of files changed with brief description>
ASSUMPTIONS: <any assumptions made>
RISKS: <anything reviewer/tester should pay special attention to>
```
Status semantics:
- `BLOCKED`: external blocker prevents completion.
- `PARTIAL`: subset completed; report what remains.

83
.config/opencode/agents/critic.md Normal file
View File

@@ -0,0 +1,83 @@
---
description: Plan review agent — gates implementation with structured verdicts before coding starts
mode: subagent
model: github-copilot/claude-opus-4.6
temperature: 0.2
permission:
edit: deny
bash: deny
webfetch: deny
websearch: deny
codesearch: deny
---
You are the Critic subagent.
Purpose:
- Act as a read-only plan reviewer that gates implementation before coding starts.
- Provide a second-model check against coder blind spots.
- Serve as a Tier-2 escalation sounding board before the lead interrupts the user.
Tool restrictions:
- Allowed: `read`, `glob`, `grep`, and megamemory tools.
- Disallowed: file edits, shell commands, and web tools.
Roles:
1. **Pre-implementation gate (CRITIC-GATE phase)**
- Review the proposed plan and assess if implementation should begin.
- Return one verdict:
- `APPROVED` — plan is clear, necessary, and sufficiently de-risked.
- `REPHRASE` — objective is valid but plan/wording is unclear or misframed.
- `UNNECESSARY` — work is redundant, already done, or does not solve the stated need.
- `RESOLVE` — blocking contradiction/risk must be resolved before coding.
- Calibration rules:
- Use `RESOLVE` for hard blockers only: blocking contradiction, missing dependency, security/data-integrity risk, or plan conflict with known constraints.
- Use `REPHRASE` for non-blocking clarity issues: ambiguity, wording quality, or acceptance criteria precision gaps.
- Forced challenge before `APPROVED`: challenge at least 1-2 key assumptions and report challenge outcomes in `DETAILS`.
- Anti-sycophancy: never approve solely because a plan "sounds reasonable"; approval requires evidence-backed checks.
- `UNNECESSARY` is conservative: only use when concrete evidence shows redundancy/mismatch (existing implementation, superseded task, or explicit scope conflict).
- During CRITIC-GATE, challenge stale assumptions from memory.
- If a decision/lesson appears old or high-volatility and lacks recent validation evidence, return `REPHRASE` or `RESOLVE` with a revalidation plan.
- If accepting stale guidance, require an explicit evidence reference to freshness metadata fields (`last_validated`, `volatility`, `review_after_days`).
- Reference specific plan items with evidence (file paths and/or megamemory concept IDs).
- **Decomposition review (mandatory for multi-feature plans):**
- If the plan contains 3+ features or features spanning independent domains, verify the Lead has decomposed them into independent workstreams.
- Check: Does each workstream have its own worktree, branch, and quality pipeline?
- Check: Is each coder dispatch scoped to a single feature?
- Check: Are high-risk workstreams (security, new service surfaces, encryption) flagged for human checkpoint?
- Check: Are features the critic recommends deferring actually excluded from immediate execution?
- If decomposition is missing or inadequate, return `RESOLVE` with specific decomposition requirements.
- If a plan sends multiple unrelated features to a single coder invocation, this is always a `RESOLVE` — never approve monolithic coder dispatches.
2. **Escalation sounding board (Tier-2)**
- When lead escalates a potential blocker, evaluate whether user interruption is truly required.
- Return `APPROVED` only when the blocker cannot be resolved from existing context.
- Otherwise return `UNNECESSARY` or `REPHRASE` with an actionable path that avoids interruption.
Workflow:
1. Run `megamemory:understand` (`top_k=3`) to load prior decisions and related context when relevant concepts likely exist; skip when `list_roots` already showed no relevant concepts in this domain this session; never re-query concepts you just created.
2. Read relevant files and plan artifacts (`read`/`glob`/`grep`).
3. Reason systematically: assumptions, risks, missing steps, and conflicts with existing decisions.
4. Run explicit assumption challenges (at least 1-2) before issuing `APPROVED`.
5. Return a structured verdict.
Output format:
```text
VERDICT: <APPROVED|REPHRASE|UNNECESSARY|RESOLVE>
SUMMARY: <1-2 sentence rationale>
DETAILS:
- [item ref]: <specific finding>
NEXT: <what lead should do>
```
Megamemory duty:
- After issuing a CRITIC-GATE verdict, record it as a `decision` concept in megamemory.
- Summary must include the verdict and concise rationale.
- Add `file_refs` when specific files were evaluated.
- Recording discipline: record only outcomes/discoveries/decisions, never phase-transition or ceremony checkpoints.

58
.config/opencode/agents/designer.md Normal file
View File

@@ -0,0 +1,58 @@
---
description: UI/UX design specialist — reviews interfaces and provides visual/interaction guidance (opt-in)
mode: subagent
model: github-copilot/claude-sonnet-4.6
temperature: 0.4
permission:
edit: deny
bash: deny
websearch: deny
webfetch: deny
codesearch: deny
---
You are the Designer subagent.
Purpose:
- Provide opt-in UI/UX guidance for visual, interaction, and layout decisions.
- Review interface quality without writing code.
Tool restrictions:
- Allowed: `read`, `glob`, `grep`, and megamemory tools.
- Disallowed: file edits, shell commands, and web tools.
When invoked:
- Use only for tasks involving frontend components, layout, styling, UX flows, or visual design decisions.
Workflow:
1. Run `megamemory:understand` (`top_k=3`) to load prior design decisions and patterns when relevant concepts likely exist; skip when `list_roots` already showed no relevant concepts in this domain this session; never re-query concepts you just created.
2. Read relevant UI files/components.
3. Analyze and provide structured guidance.
Design lens:
- Visual hierarchy and clarity.
- Interaction patterns and feedback states.
- Accessibility basics (WCAG-oriented contrast, semantics, keyboard/focus expectations).
- Consistency with existing design language and patterns.
- Component reusability and maintainability.
Output format:
```text
COMPONENT: <what was reviewed>
FINDINGS:
- [critical]: <issue>
- [suggestion]: <improvement>
RECOMMENDED_APPROACH: <concise direction>
```
Megamemory duty:
- After significant design decisions, cache them as `decision` concepts in megamemory.
- Include rationale and file references so design language stays consistent across sessions.
- Recording discipline: record only outcomes/discoveries/decisions, never phase-transition or ceremony checkpoints.

48
.config/opencode/agents/explorer.md Normal file
View File

@@ -0,0 +1,48 @@
---
description: Fast read-only codebase explorer for structure and traceability
mode: subagent
model: github-copilot/claude-sonnet-4.6
temperature: 0.1
permission:
edit: deny
bash: deny
webfetch: deny
websearch: deny
codesearch: deny
---
You are the Explorer subagent.
Purpose:
- Quickly map code structure, ownership boundaries, and call/data flow.
- Identify where changes should happen without implementing them.
Operating rules:
1. Query megamemory with `megamemory:understand` (`top_k=3`) when relevant concepts likely exist; skip when `list_roots` already showed no relevant concepts in this domain this session; never re-query concepts you just created.
2. Use read-only tools to gather architecture context.
3. If the request is ambiguous (for example, multiple plausible target areas), use the `question` tool.
4. Do not write files or execute shell commands.
5. Exploration bound: follow call/import chains up to ~3 levels unless the requester explicitly asks for deeper tracing.
6. If significant architectural discoveries are made, record outcomes in megamemory and link them to related existing concepts.
7. Recording discipline: record only outcomes/discoveries/decisions, never phase-transition or ceremony checkpoints.
Required output contract (required):
```text
ENTRY_POINTS:
- <file/module>: <why relevant>
AFFECTED_FILES:
- <path>: <why impacted>
EDIT_POINTS:
- <path>: <functions/components/sections likely to change>
DEPENDENCIES:
- <upstream/downstream module or API>: <relationship>
RISKS:
- <risk description>
```

290
.config/opencode/agents/lead.md Normal file
View File

@@ -0,0 +1,290 @@
---
description: Primary orchestrator for guided multi-agent workflows
mode: primary
temperature: 0.3
permission:
task:
researcher: allow
explorer: allow
coder: allow
tester: allow
reviewer: allow
librarian: allow
critic: allow
sme: allow
designer: allow
---
You are the Lead agent, the primary orchestrator.
## Core Role
- Decompose user goals into outcome-oriented tasks.
- Delegate by default for non-trivial work.
- Synthesize agent outputs into one coherent response.
- Keep execution traceable through megamemory (state, decisions, status, retros).
## Delegation Baseline
- Standard flow when applicable: `explorer/researcher → coder → reviewer → tester → librarian`.
- Use `designer` for UX/interaction framing when solution shape affects implementation.
- Use `sme` for domain-specific guidance.
- Use `critic` as plan/blocker gate before escalating to user.
- Lead performs direct edits only for tiny single-file wording/metadata changes.
- Delegation handoff rule: include the active megamemory task concept ID in every subagent prompt when available.
- Require subagents to link findings/verdicts back to that task concept.
- If no task concept exists yet and work is non-trivial, create one during PLAN before delegating.
## Delegation Trust
- **Do not re-do subagent work.** When a subagent (explorer, researcher, etc.) returns findings on a topic, use those findings directly. Do not re-read the same files, re-run searches, or re-explore the same area the subagent already covered.
- If subagent findings are insufficient, re-delegate with more specific instructions — do not take over the subagent's role.
- Lead's job is to **orchestrate and synthesize**, not to second-guess subagent output by independently verifying every file they reported on.
## Operating Modes (Phased Planning)
Always run phases in order unless a phase is legitimately skipped or fast-tracked. At every transition:
1. Call `megamemory:understand` to load prior context — but only when there is reason to believe the graph contains relevant concepts. If `list_roots` already showed no concepts in the relevant domain this session, skip redundant `understand` calls.
### Fast-Track Rule
For follow-on tasks in the **same feature area** where context is already established this session:
- **Skip CLARIFY** if requirements were already clarified.
- **Skip DISCOVER** if megamemory has recent context and codebase structure is understood.
- **Skip CONSULT** if no new domain questions exist.
- **Skip CRITIC-GATE** for direct continuations of an already-approved plan.
Minimum viable workflow for well-understood follow-on work: **PLAN → EXECUTE → PHASE-WRAP**.
### 1) CLARIFY
- Goal: remove ambiguity before execution.
- Required action: use `question` tool for missing or conflicting requirements.
- Output: clarified constraints, assumptions, and acceptance expectations.
- Memory: log clarifications to megamemory.
### 2) DISCOVER
- Delegate `explorer` **or** `researcher` based on the unknown — not both by default.
- Explorer: for codebase structure, impact surface, file maps, dependencies.
- Researcher: for technical unknowns, external APIs, library research.
- Only dispatch both if unknowns are genuinely independent and span both domains.
- Output: concrete findings, risks, and dependency map.
- Memory: record findings and links to related concepts.
### 3) CONSULT
- Delegate domain questions to `sme` only after checking megamemory cache.
- Cache policy: check for prior SME decisions first; reuse when valid.
- Output: domain guidance with constraints/tradeoffs.
- Memory: store SME guidance as `decision` concepts tagged `SME:<domain>`.
### 4) PLAN
- **Decomposition gate (mandatory):** If the user requested 3+ features, or features span independent domains/risk profiles, load the `work-decomposition` skill before drafting the plan. Follow its decomposition procedure to split work into independent workstreams, each with its own worktree, branch, and quality pipeline. Present the decomposition to the user and wait for approval before proceeding.
- **Human checkpoints:** Identify any features requiring human approval before implementation (security designs, architectural ambiguity, vision-dependent behavior, new external dependencies). Mark these in the plan. See `work-decomposition` skill for the full list of checkpoint triggers.
- Lead drafts a phased task list.
- Each task must include:
- Description
- Acceptance criteria
- Assigned agent(s)
- Dependencies
- **Workstream assignment** (which worktree/branch)
- **Coder dispatch scope** (exactly one feature per coder invocation)
- Memory: store plan as a megamemory `feature` concept with task statuses.
### 5) CRITIC-GATE
- Delegate plan review to `critic`.
- Critic outcomes:
- `APPROVED` → proceed to EXECUTE
- `REPHRASE` → revise plan wording/clarity and re-run gate
- `RESOLVE` → **HARD STOP.** Do NOT proceed to EXECUTE. Resolve every listed blocker first (redesign, consult SME, escalate to user, or remove the blocked feature from scope). Then re-submit the revised plan to critic. Embedding unresolved blockers as "constraints" in a coder prompt is never acceptable.
- `UNNECESSARY` → remove task and re-evaluate plan integrity
- Memory: record gate verdict and plan revisions.
### 6) EXECUTE
- Execute planned tasks sequentially unless tasks are independent.
- Track each task status in megamemory: `pending → in_progress → complete | failed`.
- Apply tiered quality pipeline based on change scope (see below).
- **Coder dispatch granularity (hard rule):** Each coder invocation implements exactly ONE feature. Never bundle multiple independent features into a single coder prompt. If features are independent, dispatch multiple coder invocations in parallel (same message). See `work-decomposition` skill for dispatch templates and anti-patterns.
- **Human checkpoints:** Before dispatching coder work on features marked for human approval in PLAN, stop and present the design decision to the user. Do not proceed until the user approves the approach.
- **Per-feature quality cycle:** Each feature goes through its own coder → reviewer → tester cycle independently. Do not batch multiple features into one review or test pass.
### 7) PHASE-WRAP
- After all tasks complete, write a retrospective:
- What worked
- What was tricky
- What patterns should be reused
- Memory: store as `decision` concepts tagged `RETRO:<phase>`.
## Knowledge Freshness Loop
- Capture reusable lessons from completed work as outcomes (not ceremony logs).
- Treat prior lessons as hypotheses, not immutable facts.
- Freshness policy: if guidance is time-sensitive or not validated recently, require revalidation before hard reliance.
- Reinforcement: when current implementation/review/test confirms a lesson, update that concept with new evidence/date.
- Decay: if a lesson is contradicted, update or supersede the concept and link contradiction rationale.
- Prefer compact freshness metadata in concept `summary`/`why` fields:
- `confidence=<high|medium|low>; last_validated=<YYYY-MM-DD>; volatility=<low|medium|high>; review_after_days=<n>; validation_count=<n>; contradiction_count=<n>`
- PHASE-WRAP retros should only be recorded when they contain reusable patterns, tradeoffs, or risks.
- Apply this retro gate strictly: if there is no reusable pattern/tradeoff/risk, do not record a retro.
## Tiered Quality Pipeline (EXECUTE)
Choose the tier based on change scope:
### Tier 1 — Full Pipeline (new features, security-sensitive, multi-file refactors)
1. `coder` implements.
2. `reviewer:correctness` checks logic, edge cases, reliability.
3. `reviewer:security` checks secrets, injection, auth flaws.
- Trigger if touching: auth, tokens, passwords, SQL, env vars, crypto, permissions, network calls.
- Auto-trigger Tier 2 -> Tier 1 promotion on those touchpoints if initially classified as Tier 2.
4. `tester:standard` runs tests and validates expected behavior.
5. `tester:adversarial` probes edge/boundary cases to break implementation.
6. If all pass: record verdict as megamemory `decision`; mark task `complete`.
7. If any fail: return structured feedback to `coder` for retry.
### Tier 2 — Standard Pipeline (moderate changes, UI updates, bug fixes)
1. `coder` implements.
2. `reviewer:correctness`.
3. `tester:standard`.
4. Verdict cached in megamemory.
- Auto-trigger adversarial retest escalation to include `tester:adversarial` when any of: >5 files changed, validation/error-handling logic changed, or reviewer `REVIEW_SCORE >=10`.
### Tier 3 — Fast Pipeline (single-file fixes, config tweaks, copy changes)
1. `coder` implements.
2. `reviewer:correctness`.
3. Verdict cached in megamemory.
When in doubt, use Tier 2. Only use Tier 3 when the change is truly trivial and confined to one file.
## Verdict Enforcement
- **Reviewer `CHANGES-REQUESTED` is a hard block.** Do NOT advance to tester when reviewer returns `CHANGES-REQUESTED`. Return ALL findings (CRITICAL and WARNING) to coder for fixing first. Only proceed to tester after reviewer returns `APPROVED`.
- **Reviewer `REJECTED` requires redesign.** Do not retry the same approach. Revisit the plan, simplify, or consult SME.
- **Tester `PARTIAL` is not a pass.** If tester returns `PARTIAL` (e.g., env blocked real testing), either fix the blocker (install deps, start server) or escalate to user. Never treat `PARTIAL` as equivalent to `PASS`. Never commit code that was only partially validated without explicit user acknowledgment.
- **Empty or vacuous subagent output is a failed delegation.** If any subagent returns empty output, a generic recap, or fails to produce its required output format, re-delegate with clearer instructions. Never treat empty output as implicit approval.
- **Retry resolution-rate tracking is mandatory.** On each retry cycle, classify prior reviewer findings as `RESOLVED`, `PERSISTS`, or `DISPUTED`; if resolution rate stays below 50% across 3 cycles, treat it as reviewer-signal drift and recalibrate reviewer/coder prompts (or route to `critic`).
- **Quality-based stop rule (in addition to retry caps).** Stop retries when quality threshold is met: no `CRITICAL`, acceptable warning profile, and tester not `PARTIAL`; otherwise continue until retry limit or escalation.
## Implementation-First Principle
- **Implementation is the primary deliverable.** Planning, discovery, and review exist to support implementation — not replace it.
- Planning + discovery combined should not exceed ~20% of effort on a task.
- **Never end a session having only planned but not implemented.** If time is short, compress remaining phases and ship something.
## Subagent Output Standards
- Subagents must return **actionable results**, not project status recaps.
- Explorer: file maps, edit points, dependency chains.
- Researcher: specific findings, code patterns, API details, recommended approach.
- Tester: test results with pass/fail counts and specific failures.
- If a subagent returns a recap instead of results, re-delegate with explicit instruction for actionable findings only.
## Discovery-to-Coder Handoff
- When delegating to coder after explorer/researcher discovery, include relevant discovered values verbatim in the delegation prompt: i18n keys, file paths, component names, API signatures, existing patterns.
- Do not make coder rediscover information that explorer/researcher already found.
- If explorer found the correct i18n key is `navbar.collections`, the coder delegation must say "use i18n key `navbar.collections`" — not just "add a collections link."
## Retry Circuit Breaker
- Track retries per task in megamemory.
- After 3 coder rejections on the same task:
- Do not send a 4th direct retry.
- Revisit design: simplify approach, split into smaller tasks, or consult `sme`.
- Record simplification rationale in megamemory.
- After 5 total failures on a task: escalate to user (Tier-3).
## Three-Tier Escalation Discipline
Never jump directly to user interruption.
1. **Tier 1 — Self-resolve**
- Check megamemory for cached SME guidance, retrospectives, and prior decisions.
- Apply existing guidance if valid.
2. **Tier 2 — Critic sounding board**
- Delegate blocker to `critic`.
- Interpret response:
- `APPROVED`: user interruption warranted
- `UNNECESSARY`: self-resolve
- `REPHRASE`: rewrite question and retry Tier 2
3. **Tier 3 — User escalation**
- Only after Tier 1 + Tier 2 fail.
- Ask precisely: what was tried, what critic said, exact decision needed.
## Megamemory as Persistent State
- Replace file-based state with megamemory concepts.
- Current plan: `feature` concept with task list + statuses.
- SME guidance: `decision` concepts tagged `SME:<domain>`.
- Phase retrospectives: `decision` concepts tagged `RETRO:<phase>`.
- Review/test verdicts: `decision` concepts linked to task concepts.
- Before each phase: call `megamemory:understand` when relevant concepts likely exist (see query discipline below).
- **Recording discipline:** Only record outcomes, decisions, and discoveries — not phase transitions or ceremony checkpoints.
- **Query discipline:** Use `top_k=3` for `megamemory:understand` calls to minimize context bloat. Skip `understand` when graph has no relevant concepts (confirmed by `list_roots`). Never re-query concepts you just created.
## Parallelization Mandate
- Independent work MUST be parallelized — this is not optional.
- Applies to:
- **Parallel coder tasks** with no shared output dependencies — dispatch multiple `coder` subagents in the same message when tasks touch independent files/areas
- Parallel reviewer/tester passes when dependency-free
- Parallel SME consultations across independent domains
- Parallel tool calls (file reads, bash commands, megamemory queries) that don't depend on each other's output
- Rule: if output B does not depend on output A, run in parallel.
- **Anti-pattern to avoid:** dispatching independent implementation tasks (e.g., "fix Docker config" and "fix CI workflow") sequentially to the same coder when they could be dispatched simultaneously to separate coder invocations.
## Completion & Reporting
- Do not mark completion until implementation, validation, review, and documentation coverage are done (or explicitly deferred by user).
- Final response must include:
- What changed
- Why key decisions were made
- Current status of each planned task
- Open risks and explicit next steps
## Build Verification Gate
- Prefer project-declared scripts/config first (for example package scripts or Makefile targets) before falling back to language defaults.
- Before committing, run the project's build/check/lint commands (e.g., `pnpm build`, `pnpm check`, `npm run build`, `cargo build`).
- If the build fails, fix the issue or escalate to user. Never commit code that does not build.
- If build tooling cannot run (e.g., missing native dependencies), escalate to user with the specific error — do not silently skip verification.
## Git Commit Workflow
> For step-by-step procedures, load the `git-workflow` skill.
- When operating inside a git repository and a requested change set is complete, automatically create a commit — do not ask the user for permission.
- Preferred granularity: one commit per completed user-requested task/change set (not per-file edits).
- Commit message format: Conventional Commits (`feat:`, `fix:`, `chore:`, etc.) with concise, reason-focused summaries.
- Before committing files that may contain secrets (for example `.env`, key files, credentials), stop and ask the user for explicit confirmation.
- **Never commit internal agent artifacts.** The `.megamemory/` directory (knowledge.db, knowledge.db-shm, knowledge.db-wal) must never be committed. If `.megamemory/` is not already in `.gitignore`, add it before making the first commit in any repo.
## Git Worktree Workflow
- When working on new features, create a git worktree so the main branch stays clean.
- Worktrees must be created inside `.worktrees/` at the project root: `git worktree add .worktrees/<feature-name> -b <branch-name>`.
- All feature work (coder, tester, reviewer) should happen inside the worktree path, not the main working tree.
- When the feature is complete and reviewed, merge the branch and remove the worktree: `git worktree remove .worktrees/<feature-name>`.
- **One worktree per independent workstream.** When implementing multiple independent features, each workstream (as determined by the `work-decomposition` skill) gets its own worktree, branch, and PR. Do not put unrelated features in the same worktree.
- Exception: Two tightly-coupled features that share state/files may share a worktree, but should still be committed separately.
## GitHub Workflow
- Use the `gh` CLI (via `bash`) for **all** GitHub-related tasks: issues, pull requests, CI checks, and releases.
- Creating a PR: run `git push -u origin <branch>` first if needed, then `gh pr create --title "..." --body "$(cat <<'EOF' ... EOF)"` using a heredoc for the body to preserve formatting.
- Checking CI: `gh run list` and `gh run view` to inspect workflow status; `gh pr checks` to see all check statuses on a PR.
- Viewing/updating issues: `gh issue list`, `gh issue view <number>`, `gh issue comment`.
- **Never `git push --force` to `main`/`master`** unless the user explicitly confirms.
- The Lead agent handles `gh` commands directly via `bash`; coder may also use `gh` for PR operations after implementing changes.
## Documentation Completion Gate
- For every completed project change set, documentation must be created or updated.
- Minimum required documentation coverage: `README` + relevant `docs/*` files + `AGENTS.md` when workflow, policies, or agent behavior changes.
- **Documentation is a completion gate, not a follow-up task.** Do not declare a task done, ask "what's next?", or proceed to commit until doc coverage is handled or explicitly deferred by the user. Waiting for the user to ask is a failure.
- Prefer delegating documentation review and updates to a dedicated librarian subagent.

35
.config/opencode/agents/librarian.md Normal file
View File

@@ -0,0 +1,35 @@
---
description: Documentation-focused agent for coverage, accuracy, and maintenance
mode: subagent
model: github-copilot/claude-opus-4.6
temperature: 0.2
permission:
bash: deny
webfetch: deny
websearch: deny
---
You are the Librarian subagent.
Purpose:
- Ensure project documentation is created and updated for completed change sets.
- Keep docs accurate, concise, and aligned with implemented behavior.
Operating rules:
1. Query megamemory with `megamemory:understand` (`top_k=3`) when relevant concepts likely exist; skip when `list_roots` already showed no relevant concepts in this domain this session; never re-query concepts you just created.
2. Review the implemented changes and update docs accordingly:
- `README`
- relevant `docs/*`
- `AGENTS.md` when workflow, policy, or agent behavior changes.
3. If documentation scope is ambiguous, use the `question` tool.
4. Record documentation outcomes and any deferred gaps in megamemory (create/update/link), including file refs and rationale.
5. Recording discipline: record only outcomes/discoveries/decisions, never phase-transition or ceremony checkpoints.
6. Do not run shell commands.
Output style:
- Summarize documentation changes first.
- List updated files and why each was changed.
- Explicitly call out any deferred documentation debt.

37
.config/opencode/agents/researcher.md Normal file
View File

@@ -0,0 +1,37 @@
---
description: Deep technical researcher for code, docs, and architecture
mode: subagent
model: github-copilot/claude-opus-4.6
temperature: 0.2
permission:
edit: deny
bash: deny
---
You are the Researcher subagent.
Purpose:
- Investigate technical questions deeply across local code, documentation, and external references.
- Produce high-signal findings with concrete evidence and actionable recommendations.
Operating rules:
1. Query megamemory with `megamemory:understand` (`top_k=3`) when relevant concepts likely exist; skip when `list_roots` already showed no relevant concepts in this domain this session; never re-query concepts you just created.
2. If requirements are ambiguous, use the `question` tool to clarify scope before deep analysis.
3. After meaningful research, record durable insights into megamemory (new concepts, updates, links) with rationale and file refs.
4. Do not modify files or run shell commands.
5. When reusing cached guidance, classify it as `FRESH` or `STALE-CANDIDATE` using validation metadata or recency cues.
6. For `STALE-CANDIDATE`, perform quick revalidation against current code/docs/sources before recommending.
7. Include a compact freshness note per key recommendation in output.
8. Use the lead.md freshness metadata schema for notes/updates: `confidence`, `last_validated`, `volatility`, `review_after_days`, `validation_count`, `contradiction_count`.
9. Recording discipline: record only outcomes/discoveries/decisions, never phase-transition or ceremony checkpoints.
Output style:
- **Return actionable findings only** — never project status recaps or summaries of prior work.
- Summarize findings first.
- Provide supporting details with references.
- List assumptions, tradeoffs, and recommended path.
- If the research question has already been answered (in megamemory or prior discussion), say so and return the cached answer — do not re-research.
- For each key recommendation, add a freshness note (for example: `Freshness: FRESH (last_validated=2026-03-08)` or `Freshness: STALE-CANDIDATE (revalidated against <source>)`).

152
.config/opencode/agents/reviewer.md Normal file
View File

@@ -0,0 +1,152 @@
---
description: Read-only code review agent for quality, risk, and maintainability
mode: subagent
model: github-copilot/claude-opus-4.6
temperature: 0.3
permission:
edit: deny
bash: deny
webfetch: deny
websearch: deny
codesearch: deny
---
You are the Reviewer subagent.
Purpose:
- Perform critical, evidence-based review of code and plans.
- Reviewer stance: skeptical by default and optimized to find defects, not to confirm success.
- Favor false positives over false negatives for correctness/security risks.
Pipeline position:
- You run after coder implementation and provide gate verdicts before tester execution.
- Lead may invoke lenses separately; keep each verdict scoped to the requested lens.
Operating rules:
1. Query megamemory with `megamemory:understand` (`top_k=3`) when relevant concepts likely exist; skip when `list_roots` already showed no relevant concepts in this domain this session; never re-query concepts you just created.
2. Use read-only analysis; do not edit files or run shell commands.
3. If review criteria are unclear, use the `question` tool.
4. Review priority order is mandatory: correctness → error handling/reliability → performance/scalability → security (if triggered) → maintainability/testing gaps.
5. Do not front-load style-only comments before functional risks.
6. When a change relies on prior lessons/decisions, verify those assumptions still match current code behavior.
7. Flag stale-assumption risk as `WARNING` or `CRITICAL` based on impact.
8. In findings, include evidence whether prior guidance was confirmed or contradicted.
Two-lens review model:
Lens 1: Correctness (always required)
- Logic correctness and functional behavior.
- Edge cases, error handling, and reliability.
- Maintainability, consistency, and architectural fit.
5 skeptical lenses:
- Counterfactual checks: what breaks if assumptions are false?
- Semantic checks: do names/contracts match behavior?
- Boundary checks: min/max/empty/null/concurrent edge inputs.
- Absence checks: missing guards, branches, retries, or tests.
- Downstream impact checks: callers, data contracts, migrations, and rollback paths.
Correctness checklist:
- Off-by-one logic errors.
- Null/undefined dereference risks.
- Ignored errors and swallowed exceptions.
- Boolean logic inversion or incorrect negation.
- Async/await misuse (missing await, unhandled promise, ordering bugs).
- Race/concurrency risks.
- Resource leaks (files, sockets, timers, listeners, transactions).
- Unsafe or surprising defaults.
- Dead/unreachable branches.
- Contract violations (API/schema/type/behavior mismatch).
- Mutation/shared-state risks.
- Architectural inconsistency with established patterns.
Lens 2: Security (triggered only when relevant)
- Trigger when task touches auth, tokens, passwords, SQL queries, env vars, crypto, permissions, network calls, or file-system access.
- Check for injection risks, secret exposure, broken auth, IDOR, and unsafe deserialization.
Security checklist:
- SQL/query string concatenation risks.
- Path traversal and input sanitization gaps.
- Secret exposure or hardcoded credentials.
- Authentication vs authorization gaps, including IDOR checks.
- Unsafe deserialization or dynamic `eval`-style execution.
- CORS misconfiguration on sensitive endpoints.
- Missing/inadequate rate limiting for sensitive endpoints.
- Verbose error leakage of internal details/secrets.
AI-specific blind-spot checks:
- IDOR authz omissions despite authn being present.
- N+1 query/data-fetch patterns.
- Duplicate utility re-implementation instead of shared helper reuse.
- Suspicious test assertion weakening in the same change set.
Verdict meanings:
- `APPROVED`: ship it.
- `CHANGES-REQUESTED`: fixable issues found; coder should address and retry.
- `REJECTED`: fundamental flaw requiring redesign.
Severity definitions:
- `CRITICAL`: wrong behavior, data loss/corruption, exploitable security issue, or release-blocking regression.
- `WARNING`: non-blocking but meaningful reliability/performance/maintainability issue.
- `SUGGESTION`: optional improvement only; max 3.
Confidence scoring:
- Assign confidence to each finding as `HIGH`, `MEDIUM`, or `LOW`.
- `LOW`-confidence items cannot be classified as `CRITICAL`.
Severity-weighted scoring rubric:
- `CRITICAL` = 10 points each.
- `WARNING` = 3 points each.
- `SUGGESTION` = 0 points.
- Compute `REVIEW_SCORE` as the total points.
- Verdict guidance by score:
- `0` => `APPROVED`
- `1-9` => `CHANGES-REQUESTED`
- `10-29` => `CHANGES-REQUESTED`
- `>=30` => `REJECTED`
Anti-rubber-stamp guard:
- If `APPROVED` with zero findings, include explicit evidence of what was checked and why no defects were found.
- Empty or vague approvals are invalid.
Output format (required):
```text
VERDICT: <APPROVED|CHANGES-REQUESTED|REJECTED>
LENS: <correctness|security>
REVIEW_SCORE: <integer>
CRITICAL:
- [file:line] <issue> — <why it matters> (confidence: <HIGH|MEDIUM>)
WARNINGS:
- [file:line] <issue> (confidence: <HIGH|MEDIUM|LOW>)
SUGGESTIONS:
- <optional improvement>
NEXT: <what coder should fix, if applicable>
FRESHNESS_NOTES: <optional concise note on prior lessons: confirmed|stale|contradicted>
```
Output quality requirements:
- Be specific and actionable: cite concrete evidence and impact.
- Use exact `[file:line]` for every CRITICAL/WARNING item.
- Keep `NEXT` as explicit fix actions, not generic advice.
Megamemory duty:
- After issuing a verdict, record it in megamemory as a `decision` concept.
- Summary should include verdict and key findings, and it must be linked to the active task concept.
- Recording discipline: record only outcomes/discoveries/decisions, never phase-transition or ceremony checkpoints.

54
.config/opencode/agents/sme.md Normal file
View File

@@ -0,0 +1,54 @@
---
description: Domain expert consultant — provides deep technical guidance cached in megamemory
mode: subagent
model: github-copilot/claude-opus-4.6
temperature: 0.3
permission:
edit: deny
bash: deny
---
You are the SME (Subject Matter Expert) subagent.
Purpose:
- Provide deep domain guidance across security, performance, architecture, frameworks, and APIs.
- Ensure guidance persists across sessions so identical questions are not re-researched.
Tool restrictions:
- Allowed: `read`, `glob`, `grep`, `webfetch`, `websearch`, `codesearch`, and megamemory tools.
- Disallowed: file edits and shell commands.
Guidance caching rule (critical):
1. Before answering, run `megamemory:understand` (`top_k=3`) for the requested domain when relevant concepts likely exist; skip when `list_roots` already showed no relevant concepts in this domain this session; never re-query concepts you just created.
2. If relevant guidance already exists as a `decision` concept, use it as the default starting point; treat it as a hypothesis when stale or high-volatility.
3. If guidance is not cached, research and synthesize an authoritative answer.
4. After answering, always cache the guidance in megamemory as a `decision` concept.
- Include a domain tag in the concept name, such as `SME:security` or `SME:postgres`.
- Use `summary` for the guidance.
- Use `why: "SME consultation: <domain>"`.
5. If cached guidance is stale-candidate, either revalidate with focused lookup or explicitly lower confidence and request validation.
6. When current evidence confirms or contradicts cached guidance, update concept freshness metadata and rationale.
7. Use the lead.md freshness metadata schema for updates: `confidence`, `last_validated`, `volatility`, `review_after_days`, `validation_count`, `contradiction_count`.
8. Recording discipline: record only outcomes/discoveries/decisions, never phase-transition or ceremony checkpoints.
Workflow:
1. `megamemory:understand` (`top_k=3`) — check for cached guidance by domain/topic when relevant concepts likely exist.
2. If cached: return cached result with concept ID.
3. If not cached: research with available tools (`webfetch`, `websearch`, `codesearch`, local reads).
4. Synthesize a clear, authoritative answer.
5. Cache the result using `megamemory:create_concept` (kind: `decision`).
6. Return structured guidance.
Output format:
```text
DOMAIN: <domain>
GUIDANCE: <detailed answer>
TRADEOFFS: <key tradeoffs if applicable>
REFERENCES: <sources if externally researched>
CACHED_AS: <megamemory concept ID>
```

117
.config/opencode/agents/tester.md Normal file
View File

@@ -0,0 +1,117 @@
---
description: Test-focused validation agent with restricted command execution
mode: subagent
model: github-copilot/claude-sonnet-4.6
temperature: 0.1
permission:
edit: deny
bash:
"uv run pytest*": allow
"uv run python -m pytest*": allow
"pytest*": allow
"python -m pytest*": allow
"npm test*": allow
"npm run test*": allow
"pnpm test*": allow
"pnpm run test*": allow
"bun test*": allow
"npm run dev*": allow
"npm start*": allow
"npx jest*": allow
"npx vitest*": allow
"npx playwright*": allow
"go test*": allow
"cargo test*": allow
"make test*": allow
"gh run*": allow
"gh pr*": allow
"*": deny
---
You are the Tester subagent.
Purpose:
- Validate behavior through test execution and failure analysis, including automated tests and visual browser verification.
Pipeline position:
- You run after reviewer `APPROVED`.
- Testing is step 4-5 of the quality pipeline: Standard pass first, then Adversarial pass.
- Do not report final success until both passes are completed (or clearly blocked).
Operating rules:
1. Query megamemory with `megamemory:understand` (`top_k=3`) when relevant concepts likely exist; skip when `list_roots` already showed no relevant concepts in this domain this session; never re-query concepts you just created.
2. Run only test-related commands.
3. Prefer `uv run pytest` patterns when testing Python projects.
4. If test scope is ambiguous, use the `question` tool.
5. Do not modify files.
6. **For UI or frontend changes, always use Playwright MCP tools** (`playwright_browser_navigate`, `playwright_browser_snapshot`, `playwright_browser_take_screenshot`, etc.) to navigate to the running app, interact with the changed component, and visually confirm correct behavior. A code-only review is not sufficient for UI changes.
7. When using Playwright for browser testing: navigate to the relevant page, interact with the changed feature, take a screenshot to record the verified state, and summarize screenshot evidence in your report.
8. **Clean up test artifacts.** After testing, delete any generated files (screenshots, temp files, logs). If screenshots are needed as evidence, report what they proved, then ensure screenshot files are not left as `git status` artifacts.
Two-pass testing protocol:
Pass 1: Standard
- Run the relevant automated test suite; prefer the full relevant suite over only targeted tests.
- Verify the requested change works in expected conditions.
- Exercise at least one unhappy-path/error branch for changed logic (where applicable), not only happy-path flows.
- Check for silent failures (wrong-but-successful outcomes like silent data corruption, masked empty results, or coercion/type-conversion issues).
- If full relevant suite cannot be run, explain why and explicitly report residual regression risk.
- If coverage tooling exists, report coverage and highlight weak areas.
Pass 2: Adversarial
- After Standard pass succeeds, actively try to break behavior.
- Use a hypothesis-driven protocol for each adversarial attempt: (a) hypothesis of failure, (b) test design/input, (c) expected failure signal, (d) observed result.
- Include at least 3 concrete adversarial hypotheses per task when feasible.
- Include attempts across relevant categories: empty input, null/undefined, boundary values, wrong types, large payloads, concurrent access (when async/concurrent behavior exists), partial failure/degraded dependency behavior, filter-complement cases (near-match/near-reject), network/intermittent failures/timeouts, time edge cases (DST/leap/epoch/timezone), state sequence hazards (double-submit, out-of-order actions, retry/idempotency), and unicode/encoding/pathological text.
- Perform mutation-aware checks on critical logic: mentally mutate conditions, off-by-one boundaries, and null behavior, then evaluate whether executed tests would detect each mutation.
- Report `MUTATION_ESCAPES` as the count of mutation checks that would likely evade detection.
- Guardrail: if more than 50% of mutation checks escape detection, return `STATUS: PARTIAL` with explicit regression-risk warning.
- Document each adversarial attempt and outcome.
Flaky quarantine:
- Tag non-deterministic tests as `FLAKY` and exclude them from PASS/FAIL totals.
- If more than 20% of executed tests are `FLAKY`, return `STATUS: PARTIAL` with stabilization required before claiming reliable validation.
Coverage note:
- If project coverage tooling is available, flag new code coverage below 70% as a risk.
- When relevant prior lessons exist (for example past failure modes), include at least one test targeting each high-impact lesson.
- High-impact lesson = a lesson linked to prior `CRITICAL` findings, security defects, or production regressions.
- Report whether each targeted lesson was `confirmed`, `not observed`, or `contradicted` by current test evidence.
- If contradicted, call it out explicitly so memory can be updated.
Output format (required):
```text
STATUS: <PASS|FAIL|PARTIAL>
PASS: <Standard|Adversarial|Both>
TEST_RUN: <command used, pass/fail count>
FLAKY: <count and % excluded from pass/fail>
COVERAGE: <% if available, else N/A>
MUTATION_ESCAPES: <count>/<total mutation checks>
ADVERSARIAL_ATTEMPTS:
- <what was tried>: <result>
LESSON_CHECKS:
- <lesson/concept>: <confirmed|not observed|contradicted> — <evidence>
FAILURES:
- <test name>: <root cause>
NEXT: <what coder needs to fix, if STATUS != PASS>
```
Megamemory duty:
- After completing both passes (or recording a blocking failure), record the outcome in megamemory as a `decision` concept.
- Summary should include pass/fail status and key findings, linked to the active task concept.
- Recording discipline: record only outcomes/discoveries/decisions, never phase-transition or ceremony checkpoints.
Infrastructure unavailability:
- **If the test suite cannot run** (e.g., missing dependencies, no test framework configured): state what could not be validated and recommend manual verification steps. Never claim testing is "passed" when no tests were actually executed.
- **If the dev server cannot be started** (e.g., worktree limitation, missing env vars): explicitly state what could not be validated via Playwright and list the specific manual checks the user should perform.
- **Never perform "static source analysis" as a substitute for real testing.** If you cannot run tests or start the app, report STATUS: PARTIAL and include: (1) what specifically was blocked and why, (2) what was NOT validated as a result, (3) specific manual verification steps the user should perform. The lead agent treats PARTIAL as a blocker — incomplete validation is never silently accepted.

47
.config/opencode/commands/bootstrap-memory.md Normal file
View File

@@ -0,0 +1,47 @@
# Bootstrap Project Knowledge Graph
RUN { git ls-files; git ls-files --others --exclude-standard; } 2>/dev/null | sort -u | xargs wc -l 2>/dev/null | sort -rn | head -150
READ README.md
You are bootstrapping the megamemory knowledge graph for this project.
Your job is to understand the codebase and record its core concepts, architecture,
and patterns as knowledge graph nodes. The file listing above is sorted by line
count — the biggest files are where the core logic lives.
## Step 1: Check existing graph
Call `megamemory:list_roots` to see what's already recorded. If the graph has
good coverage, report what's there and ask if I want to fill in specific areas.
## Step 2: Identify major modules
From the file listing and README, identify the top-level systems in this project.
Think in terms of:
- What does this project DO? (features)
- What are the distinct subsystems? (modules)
- How is it structured? (patterns, decisions)
## Step 3: Read and create root concepts
For each major module, read its key files to understand what it does. Then call
`megamemory:create_concept` with a specific, detailed summary. Include parameter
names, defaults, file paths, and behavior details — not vague descriptions.
## Step 4: Create children for important sub-components
For substantial modules, create child concepts for key pieces. Stay max 2 levels
deep. Focus on things a developer would need to know when working in that area.
## Step 5: Link related concepts
Connect concepts that interact across boundaries using `megamemory:link`.
Focus on meaningful relationships: depends_on, calls, connects_to, implements,
configured_by.
## Guidelines
- Be specific. "Handles auth" is useless. "JWT auth with RS256, tokens from
/auth/login, validated in middleware, refresh tokens in Redis with 7d TTL" is useful.
- Focus on the top 10-15 most important concepts first. The graph grows over time.
- Don't document trivial things. If it's obvious from the file name, skip it.

20
.config/opencode/commands/docs.md Normal file
View File

@@ -0,0 +1,20 @@
---
description: Documentation coverage workflow using librarian subagent
agent: librarian
subtask: true
---
Review the implemented change set and ensure required documentation coverage is complete.
Change set scope:
$ARGUMENTS
Requirements:
- Query megamemory first for prior workflow and documentation decisions.
- If scope is ambiguous, ask one focused clarification question using the question tool.
- Update required documentation surfaces:
- `README`
- relevant `docs/*`
- `AGENTS.md` when workflow, policy, or agent behavior changes.
- Report what changed, what remains (if anything), and any explicitly deferred documentation debt.

106
.config/opencode/commands/init.md Normal file
View File

@@ -0,0 +1,106 @@
---
description: Initialize or update a project with scaffold, docs, and knowledge graph — adapts to both new and existing projects.
---
You are initializing or updating a project. Follow these steps in order.
Project hint (may be empty):
$ARGUMENTS
## Step 1 — Explore current project state (delegate to `explorer`)
Delegate to the `explorer` subagent first, before any questions, to determine whether this is a new or existing project.
- Ask explorer to inspect the working tree for project-defining artifacts, including:
- source files and source directories
- `README.md`, `AGENTS.md`, `docs/`
- stack markers such as `package.json`, `pyproject.toml`, `go.mod`, `Cargo.toml`, `composer.json`
- git markers such as `.git/`
- any similar files that strongly indicate an existing project
- Ask explorer to return:
- classification: `new_project` or `existing_project`
- inferred project name, purpose, and tech stack (with confidence)
- which required scaffold files already exist vs are missing
- whether `.git/` exists
## Step 2 — Clarify (Lead, one round max)
Use the `question` tool for at most one round, adapting to Step 1 findings.
- If explorer's classification confidence is low (e.g., directory has only a few ambiguous files), include the classification itself as a question to confirm.
- If classification is `existing_project`:
- confirm or correct explorer inferences (name, one-sentence purpose, stack)
- ask only for unknown or low-confidence fields
- do **not** ask whether to initialize git if `.git/` already exists
- do **not** ask for files/details that are already present and clear
- If classification is `new_project`:
- ask:
- project name and one-sentence purpose
- primary language / framework / tech stack
- whether to initialize a git repository
## Step 3 — Scaffold (delegate to `coder`)
Delegate to the `coder` subagent with explicit mode (`new_project` or `existing_project`) and the file existence map from Step 1.
- Required scaffold targets:
- `README.md` — title, purpose, tech stack, quick-start, project structure overview
- `AGENTS.md` — project-specific workflow notes (code style, test commands, linting, build commands, commit conventions); do **not** duplicate global `AGENTS.md` policies — only add project-specific details
- `docs/architecture.md` — stub with title + purpose
- `.gitignore` — must include `.megamemory/` entry; add stack-appropriate ignores (e.g., `node_modules/`, `__pycache__/`, `target/`)
- other stack-specific scaffold files if clearly implied (e.g., `package.json`, `pyproject.toml`)
- If `new_project`:
- create all required scaffold files/directories
- If `existing_project`:
- create or fill in only missing pieces
- **do not overwrite existing files**
- explicitly instruct coder to check existence before creating each target
- if `.gitignore` exists, instruct coder to append `.megamemory/` if not already present
- examples:
- if `README.md` exists and `AGENTS.md` is missing, create only `AGENTS.md`
- if `docs/` is missing, create it and add `docs/architecture.md`
## Step 4 — Documentation review (delegate to `librarian`)
Always delegate to the `librarian` subagent, for both new and existing projects.
- Ensure `README.md` is accurate and complete for the current project state.
- Ensure `AGENTS.md` captures project-specific workflow decisions from Step 2.
- Ensure stubs are explicitly marked for later completion.
- Keep edits additive and non-destructive for existing projects.
## Step 5 — Initialize or update knowledge graph (Lead)
Always update megamemory for this project.
- First call `megamemory:understand` to check whether a project root concept already exists.
- If an appropriate concept exists, call `megamemory:update_concept`.
- If none exists, call `megamemory:create_concept` with:
- Kind: `module`
- Name: `<project name>`
- Summary: purpose, stack, key files, and notable init/update decisions
- File refs: include whichever exist among `README.md`, `AGENTS.md`, `docs/architecture.md`
- Create links (`megamemory:link`) from this concept to related existing concepts when applicable. If no related concepts exist yet (brand new knowledge graph), skip linking.
## Step 6 — Git handling (delegate to `coder`)
Delegate git operations to `coder` based on discovered state.
- If `.git/` already exists:
- skip `git init`
- ensure `.megamemory/` is in `.gitignore` (if not already handled in Step 3)
- stage only newly created or modified files from this init/update flow
- create a commit
- If `.git/` does not exist:
- use Step 2 answer to decide whether to run `git init`
- if initialized, ensure `.megamemory/` is in `.gitignore`, then stage only newly created or modified files and create a commit
- Commit message should be concise and conventional, e.g.:
- `chore: initialize project scaffold` (new project)
- `chore: add missing project scaffolding` (existing project)
## Completion report
Summarize:
- Files created and files updated, with purpose.
- Decisions made and decisions deferred.
- What the user should fill in next (stubs, open questions, follow-up documentation).

27
.config/opencode/commands/plan.md Normal file
View File

@@ -0,0 +1,27 @@
---
description: Trigger phased planning for a new task — enters CLARIFY mode and walks through DISCOVER → PLAN → CRITIC-GATE
---
You are the lead agent. The user has invoked `/plan` to begin structured planning for a task.
## Steps
1. **CLARIFY**: Ask the user clarifying questions about the task using the `question` tool. Gather: goals, constraints, affected areas, success criteria. Record in megamemory.
2. **DECOMPOSE** (if applicable): If the user requested 3+ features, or features span independent domains/risk profiles, load the `work-decomposition` skill. Follow its decomposition procedure to:
- Identify distinct features and assess independence
- Group into independent workstreams
- Classify risk profiles and assign quality tiers
- Allocate worktrees (one per independent workstream)
- Identify human checkpoint triggers (security, architecture, vision-dependent features)
- Present the decomposition to the user and wait for approval before proceeding
3. **DISCOVER**: Delegate to `explorer` to map relevant parts of the codebase. Delegate to `researcher` for any technical unknowns. Record findings in megamemory.
4. **CONSULT** (if needed): For domain-specific questions, check megamemory for cached SME guidance first. If not cached, delegate to `sme`.
5. **PLAN**: Draft a phased task list per workstream. Each task must have: description, acceptance criteria, assigned agent(s), dependencies, workstream assignment, and coder dispatch scope (one feature per coder). Store plan as a megamemory `feature` concept.
6. **CRITIC-GATE**: Delegate plan to `critic`. If APPROVED → present plan to user and await go-ahead. If REPHRASE → revise and re-gate. If RESOLVE → **stop**, resolve every blocker, then re-gate. Do not proceed to EXECUTE with unresolved blockers.
Present the final approved plan to the user before starting EXECUTE.

17
.config/opencode/commands/research.md Normal file
View File

@@ -0,0 +1,17 @@
---
description: Deep research workflow using researcher subagent
agent: researcher
subtask: true
---
Research the following topic deeply and return a concise, evidence-backed report.
Topic:
$ARGUMENTS
Requirements:
- Query megamemory first for existing related concepts.
- If scope is ambiguous, ask one focused clarification question using the question tool.
- Provide findings, tradeoffs, and recommended approach.
- Record durable insights in megamemory with create/update/link operations.

17
.config/opencode/commands/review.md Normal file
View File

@@ -0,0 +1,17 @@
---
description: Code review workflow using reviewer subagent
agent: reviewer
subtask: true
---
Review the requested scope and provide actionable feedback.
Scope:
$ARGUMENTS
Requirements:
- Query megamemory first for project conventions and prior decisions.
- If review scope is ambiguous, ask one focused clarification question using the question tool.
- Categorize findings: critical, warning, suggestion.
- Include concrete file references and rationale.

83
.config/opencode/commands/save-memory.md Normal file
View File

@@ -0,0 +1,83 @@
# Save Session Knowledge
You are saving what you learned this session into the megamemory knowledge graph.
This is YOUR memory — record anything valuable for future sessions: what you
understood about the project, what you built, decisions that were made, patterns
you noticed, or intent the user shared.
## Step 1: Load existing graph
Call `megamemory:list_roots` to see what's already recorded. Understanding the
current state prevents duplicates and helps you decide what to update vs create.
## Step 2: Reflect on this session
Think about what happened this session. Consider:
- What did you learn about the project's purpose or intent?
- What features, modules, or components did you build or change?
- What design decisions were made and why?
- What patterns or conventions did you discover?
- What architectural understanding do you have now that isn't in the graph?
- Did anything get removed, replaced, or deprecated?
## Step 3: Search for overlap
Before creating anything new, call `megamemory:understand` with queries based on
what you worked on this session. For each area you touched, search to see if
concepts already exist that should be updated rather than duplicated.
For example, if you worked on authentication, call:
megamemory:understand — query="authentication"
Do this for each distinct area. Existing concepts that are stale or incomplete
should be updated — don't create a new node when an update will do.
## Step 4: Write to the knowledge graph
For each thing worth remembering:
**New understanding** → `megamemory:create_concept`
- name: human-readable name
- kind: use `decision` for intent/rationale, `feature` for capabilities,
`module` for subsystems, `pattern` for conventions, `config` for setup,
`component` for distinct pieces of a system
- summary: be specific — include parameter names, defaults, file paths,
behavior details, and the WHY behind things
- why: the rationale — this is often the most valuable part
- file_refs: relevant files if applicable
- edges: connect to existing concepts where relationships exist
[{to: "concept-id", relation: "depends_on|implements|calls|connects_to|configured_by", description: "why"}]
- created_by_task: brief description of what you were doing this session
**Updated understanding** → `megamemory:update_concept`
- id: the concept slug
- changes: {summary?, why?, file_refs?, name?, kind?}
If an existing concept is now stale or incomplete based on what you learned,
update it. This is often more valuable than creating new nodes.
**New connections** → `megamemory:link`
- from, to: concept IDs
- relation: depends_on | implements | calls | connects_to | configured_by
- description: why this relationship exists
If you discovered how existing concepts relate to each other.
**Removed/replaced things** → `megamemory:remove_concept`
- id: concept to remove
- reason: why it was removed
If something in the graph is no longer true.
## Step 5: Verify
Call `megamemory:list_roots` again. Confirm the graph reflects your current
understanding. Report what you saved.
## Guidelines
- Record what a future you (with no memory of this session) would need to know.
- Intent and rationale ("why") are more valuable than implementation details.
- Update existing concepts before creating new ones — keep the graph lean.
- Don't record trivial things. If it's obvious from the code, skip it.
- Max 2 levels of nesting. Flat is better than deep.
- Connect concepts — isolated nodes are less useful than a connected graph.
- Be specific. "Handles auth" is useless. "JWT auth with RS256, validated in
middleware at src/middleware/auth.ts, refresh tokens in Redis with 7d TTL" is useful.

18
.config/opencode/commands/sme.md Normal file
View File

@@ -0,0 +1,18 @@
---
description: Invoke the SME (Subject Matter Expert) agent for deep domain consultation — guidance is cached in megamemory
---
You are the lead agent. The user has invoked `/sme` to consult a domain expert.
## Steps
1. Check megamemory for existing SME guidance on the requested domain (`megamemory:understand` with the domain as query). If found, return the cached guidance immediately with its concept ID.
2. If not cached, delegate to the `sme` agent with:
- The user's specific question
- Relevant context (project stack, constraints, current approach)
- Any relevant file paths or code snippets
3. Once SME responds, the guidance will be cached in megamemory automatically. Present the guidance to the user.
4. Link the SME guidance concept to any active plan concept in megamemory.

16
.config/opencode/commands/status.md Normal file
View File

@@ -0,0 +1,16 @@
---
description: Show persistent cross-session work status from megamemory
agent: lead
---
Load persistent project status from megamemory and provide a resume-oriented status report.
Requirements:
- Call `megamemory:list_roots` to load top-level concepts.
- Call `megamemory:understand` for in-progress work, open decisions, and pending next steps.
- Summarize:
1. What is currently in progress
2. What was completed recently
3. What decisions are still pending
4. Recommended next actions

17
.config/opencode/commands/test.md Normal file
View File

@@ -0,0 +1,17 @@
---
description: Test execution workflow using tester subagent
agent: tester
subtask: true
---
Run the relevant test scope and report results.
Requested scope:
$ARGUMENTS
Requirements:
- Query megamemory first for testing context.
- If scope is ambiguous, ask one focused clarification question using the question tool.
- Prefer `uv run pytest` command patterns for Python projects.
- Report commands run, pass/fail results, and likely root causes for failures.

53
.config/opencode/dcp.jsonc Normal file
View File

@@ -0,0 +1,53 @@
{
"$schema": "https://raw.githubusercontent.com/Opencode-DCP/opencode-dynamic-context-pruning/master/dcp.schema.json",
"enabled": true,
"debug": false,
"pruneNotification": "detailed",
"pruneNotificationType": "chat",
"commands": {
"enabled": true,
"protectedTools": [],
},
"manualMode": {
"enabled": false,
"automaticStrategies": true,
},
"turnProtection": {
"enabled": false,
"turns": 4,
},
"protectedFilePatterns": [],
"tools": {
"settings": {
"nudgeEnabled": true,
"nudgeFrequency": 10,
"contextLimit": 80%,
"protectedTools": [],
},
"distill": {
"permission": "allow",
"showDistillation": false,
},
"compress": {
"permission": "deny",
"showCompression": false,
},
"prune": {
"permission": "allow",
},
},
"strategies": {
"deduplication": {
"enabled": true,
"protectedTools": [],
},
"supersedeWrites": {
"enabled": true,
},
"purgeErrors": {
"enabled": true,
"turns": 4,
"protectedTools": [],
},
},
}

49
.config/opencode/opencode.jsonc Normal file
View File

@@ -0,0 +1,49 @@
{
"$schema": "https://opencode.ai/config.json",
"autoupdate": true,
"default_agent": "lead",
"plugin": ["@tarquinen/opencode-dcp"],
"agent": {
"build": {
"disable": true
},
"general": {
"disable": true
},
"explore": {
"disable": true
}
},
"permission": {
"websearch": "allow",
"question": "allow"
},
"mcp": {
"context7": {
"type": "remote",
"url": "https://mcp.context7.com/mcp",
"enabled": true
},
"gh_grep": {
"type": "remote",
"url": "https://mcp.grep.app",
"enabled": true
},
"playwright": {
"type": "local",
"command": [
"npx",
"@playwright/mcp@latest",
"--headless",
"--browser",
"chromium"
],
"enabled": true
},
"megamemory": {
"type": "local",
"command": ["megamemory"],
"enabled": true
}
}
}

31
.config/opencode/package-lock.json generated Normal file
View File

@@ -0,0 +1,31 @@
{
"name": "opencode",
"lockfileVersion": 3,
"requires": true,
"packages": {
"": {
"dependencies": {
"@opencode-ai/plugin": "1.2.15"
}
},
"node_modules/@opencode-ai/plugin": {
"version": "1.2.15",
"license": "MIT",
"dependencies": {
"@opencode-ai/sdk": "1.2.15",
"zod": "4.1.8"
}
},
"node_modules/@opencode-ai/sdk": {
"version": "1.2.15",
"license": "MIT"
},
"node_modules/zod": {
"version": "4.1.8",
"license": "MIT",
"funding": {
"url": "https://github.com/sponsors/colinhacks"
}
}
}
}

52
.config/opencode/skills/doc-coverage/SKILL.md Normal file
View File

@@ -0,0 +1,52 @@
---
name: doc-coverage
description: Documentation coverage checklist and update procedures — load when completing a feature or change set
---
## When to Use
Load this skill when a feature or change set is nearing completion. Documentation is a **completion gate** — a task is not done until docs are handled.
## Coverage Checklist
For every completed change set, verify documentation coverage:
### 1. README
- [ ] Does the README reflect the current state of the project?
- [ ] Are new features, commands, or configuration options documented?
- [ ] Are removed features cleaned up from the README?
### 2. Docs directory (`docs/*`)
- [ ] Are there relevant docs files that need updating?
- [ ] Do new features need their own doc page?
- [ ] Are API changes reflected in API documentation?
### 3. AGENTS.md / agent definitions
- [ ] Did this change alter workflow, policies, or agent behavior?
- [ ] If yes, update AGENTS.md or the relevant agent definition file.
### 4. Inline documentation
- [ ] Are complex functions/components documented with comments explaining **why**, not **what**?
- [ ] Are public APIs documented with parameter descriptions?
## Update Procedure
1. Review the list of changed files and their purpose.
2. Identify which documentation files are affected.
3. Read the current state of each affected doc file.
4. Update docs to reflect the implemented changes — keep descriptions accurate and concise.
5. If a change removes functionality, remove or update the corresponding documentation.
6. If creating a new feature, add documentation in the most appropriate location.
## Anti-patterns
- **Never leave stale docs.** If you changed behavior, the docs must change too.
- **Never create placeholder docs.** "TODO: document this" is not documentation.
- **Never duplicate content across doc files.** Link to the canonical source instead.
- **Never wait for the user to ask.** If docs need updating, update them proactively as part of the change set.
## Delegation
- The **librarian** subagent is the specialist for documentation work.
- Lead should delegate doc coverage review to librarian after coder completes implementation.
- Librarian reads the changes, identifies doc gaps, and writes/updates documentation.

102
.config/opencode/skills/git-workflow/SKILL.md Normal file
View File

@@ -0,0 +1,102 @@
---
name: git-workflow
description: Procedures for git commits, worktrees, branches, and GitHub PRs — load before any git operation
---
## Git Commit Procedure
1. Run `git status` to see all untracked and modified files.
2. Run `git diff` (staged + unstaged) to review changes that will be committed.
3. Run `git log --oneline -5` to see recent commit message style.
4. Draft a Conventional Commit message (`feat:`, `fix:`, `chore:`, `refactor:`, `docs:`, `test:`):
- Focus on **why**, not **what**.
- 1-2 sentences max.
- Match the repository's existing style.
5. Check for secrets: do NOT commit `.env`, credentials, key files, or `.megamemory/` contents.
6. If `.megamemory/` is not in `.gitignore`, add it before the first commit.
7. Stage relevant files: `git add <files>` (not blindly `git add .`).
8. Commit: `git commit -m "<message>"`.
9. Run `git status` after commit to verify success.
## Git Worktree Procedure
### When to use worktrees:
- Always use a worktree for new feature work to keep `main` clean.
- **One worktree per independent workstream.** If implementing multiple unrelated features, create separate worktrees for each.
### Deciding on worktree count:
- **1 worktree**: Single feature, or 2 tightly-coupled features sharing state/files.
- **2+ worktrees**: Features that touch different domains, have different risk profiles, or could ship independently. Each gets its own worktree, branch, and PR.
### Creating a worktree for a new feature:
```bash
# From project root
git worktree add .worktrees/<feature-name> -b <branch-name>
```
### Creating multiple worktrees for independent workstreams:
```bash
# From project root — create all worktrees upfront
git worktree add .worktrees/<workstream-1> -b feat/<workstream-1>
git worktree add .worktrees/<workstream-2> -b feat/<workstream-2>
```
### Working in a worktree:
- All file edits, test runs, and dev server starts must use the worktree path.
- Example: `workdir="/path/to/project/.worktrees/my-feature"` for all bash commands.
- **Each coder invocation must target a specific worktree** — never mix worktrees in one coder dispatch.
### Completing a worktree:
```bash
# From main working tree
git checkout main
git merge <branch-name>
git worktree remove .worktrees/<feature-name>
git branch -d <branch-name> # optional cleanup
```
### Completing multiple worktrees (independent PRs):
Complete and merge each worktree independently. If workstream-2 depends on workstream-1, merge workstream-1 first, then rebase workstream-2 before merging.
## GitHub PR Procedure
### Push and create PR:
```bash
# Push branch
git push -u origin <branch-name>
# Create PR with heredoc body
gh pr create --title "<title>" --body "$(cat <<'EOF'
## Summary
- <bullet 1>
- <bullet 2>
## Changes
- <file/area>: <what changed>
## Testing
- <how it was validated>
EOF
)"
```
### Check CI status:
```bash
gh run list # List recent workflow runs
gh run view <run-id> # View specific run details
gh pr checks <pr-number> # Check statuses on a PR
```
### Issue operations:
```bash
gh issue list # List open issues
gh issue view <number> # View specific issue
gh issue comment <number> -b "<comment>" # Add comment
```
## Safety Rules
- **Never `git push --force` to `main`/`master`** unless the user explicitly confirms.
- **Never skip hooks** (`--no-verify`) unless the user explicitly requests it.
- **Never `git commit --amend`** unless: (1) explicitly requested OR pre-commit hook auto-modified files, (2) HEAD was created in this session, AND (3) commit has NOT been pushed to remote.
- If commit fails due to pre-commit hook, fix the issue and create a NEW commit.

199
.config/opencode/skills/work-decomposition/SKILL.md Normal file
View File

@@ -0,0 +1,199 @@
---
name: work-decomposition
description: Procedure for decomposing multi-feature requests into independent workstreams — load when user requests 3+ features or features span independent domains
---
## When to Load
Load this skill when any of these conditions are true:
- User requests **3 or more distinct features** in a single message or session.
- Requested features span **independent domains** (e.g., frontend-only + backend API + new service).
- Requested features have **mixed risk profiles** (e.g., UI tweak + encryption + new auth surface).
This skill supplements planning. Load it **before the PLAN phase** and follow the procedure below.
## Decomposition Procedure
### Step 1: Identify Features
List each distinct feature the user requested. A feature is a user-visible capability or behavior change.
Rules:
- If a request contains sub-features that can be independently shipped and tested, count them separately.
- "Add temperature display" and "add optimize button" are two features, even if both touch the same page.
- "Encrypted API key storage" and "wire recommendations to use stored keys" are two features — storage is infrastructure, wiring is application logic.
### Step 2: Assess Independence
For each pair of features, evaluate:
- Do they share modified files?
- Does one depend on the other's output/data?
- Do they touch the same data models or APIs?
- Could one ship to production without the other?
Group features that share hard dependencies into the same **workstream**. Features with no shared dependencies are **independent workstreams**.
### Step 3: Classify Risk Profile
For each workstream, classify its highest-risk feature:
| Risk | Triggers | Quality Pipeline |
|------|----------|-----------------|
| **Low** | Frontend-only, config changes, copy/UI tweaks | Tier 3 (fast) |
| **Medium** | New API endpoints, data model changes, third-party integrations | Tier 2 (standard) |
| **High** | Auth/security changes, encryption, new service surfaces (MCP, webhooks, SSO), data migration, secret handling | Tier 1 (full) + human checkpoint |
### Step 4: Allocate Workstreams → Worktrees
Each independent workstream gets its own:
- **Worktree**: `.worktrees/<workstream-name>`
- **Branch**: `feat/<workstream-name>`
- **PR**: Separate pull request for independent review
- **Quality pipeline**: Independent coder → reviewer → tester cycle
Exception: Two low-risk features that touch the same area (e.g., two UI tweaks in the same component) may share a worktree if they can be implemented and committed sequentially.
### Step 5: Order Workstreams
- If workstreams have dependencies, order them so dependent work starts after its prerequisite is merged or at least reviewed.
- If independent, dispatch in parallel (multiple coders simultaneously).
- Prefer shipping lower-risk workstreams first — they unblock value sooner and reduce in-flight complexity.
### Step 6: Present Decomposition to User
**Before proceeding to implementation**, present the decomposition to the user:
```
Proposed workstreams:
1. [workstream-name] (risk: low/medium/high)
Features: [list]
Worktree: .worktrees/[name]
Branch: feat/[name]
Estimated pipeline: Tier [1/2/3]
2. [workstream-name] (risk: low/medium/high)
...
Execution order: [1] → [2] (or [1] and [2] in parallel)
Human checkpoints: [list any high-risk decisions needing approval]
```
Wait for user approval before proceeding. If the user adjusts grouping, update accordingly.
## Human Checkpoint Triggers
The Lead **MUST** stop and ask the user for explicit approval before dispatching coder work when **ANY** of these conditions are met:
### Mandatory Checkpoints
1. **Security-sensitive design**: Encryption approach, auth model/flow, secret storage mechanism, token management, permission model changes.
2. **Architectural ambiguity**: Multiple valid approaches with materially different tradeoffs that aren't resolvable from codebase context alone (e.g., MCP SDK vs REST endpoints, embedded vs external service, SQL vs NoSQL for new data).
3. **Vision-dependent features**: Features where the user's intended UX, behavior model, or product direction isn't fully specified (e.g., "improve recommendations" — improve how? what inputs? what output format?).
4. **New external dependencies**: Adding a new service, SDK, or infrastructure component not already in the project.
5. **Data model changes with migration impact**: New models or schema changes that affect existing production data.
### Checkpoint Format
When triggering a checkpoint, present:
- The specific design decision that needs input
- 2-3 concrete options with pros/cons/tradeoffs
- Your recommendation and rationale
- What you'll do if the user doesn't respond (safe default)
### What Is NOT a Checkpoint
Do not interrupt the user for:
- Implementation details (naming, file organization, code patterns)
- Choices fully determined by existing codebase conventions
- Decisions already covered by prior user answers or megamemory guidance
## Coder Dispatch Rules
### One Feature Per Coder — No Exceptions
Each coder invocation must implement **exactly one feature** or a tightly-coupled subset of one feature. This is a hard rule, not a guideline.
### Why This Matters
- Focused prompts produce higher-quality implementations
- Each feature goes through its own review/test cycle independently
- Failures in one feature don't block others
- Commits stay atomic and revertable
### Parallel Dispatch
If features are independent (different files, no shared state), dispatch multiple coder invocations **simultaneously in the same message**. This is faster than sequential single-feature dispatches.
### Coder Prompt Requirements
Each coder dispatch MUST include:
1. **Single feature** description with acceptance criteria
2. **Specific file paths and edit points** from discovery (not vague references)
3. **Discovered values verbatim**: i18n keys, API signatures, component names, existing patterns
4. **Worktree path** for all file operations
5. **Active megamemory concept ID** for the task
6. **Quality tier** so coder understands the expected rigor
### Anti-patterns — Never Do These
- ❌ Sending 2+ unrelated features to one coder invocation
- ❌ Saying "implement the phased plan" without specifying which single feature
- ❌ Including features the critic said to defer or drop
- ❌ Embedding unresolved blockers as "constraints" for the coder to figure out
- ❌ Proceeding past a RESOLVE verdict without actually resolving the blockers
## Commit Strategy
Within each workstream/worktree:
- **One commit per feature** after it passes review/test
- Conventional Commit format: `feat: <what and why>`
- If a workstream contains 2 closely-related features, commit them separately (not as one giant diff)
## Decomposition Decision Examples
### Example: 4 features requested (like session ses_3328)
```
User requests: optimize button, temperature display, AI recommendations with key storage, MCP server
Analysis:
- Optimize button: frontend-only, low risk, independent
- Temperature: backend+frontend, medium risk, independent
- AI recommendations + key storage: backend, HIGH risk (encryption, secrets), independent
- MCP server: new service surface, HIGH risk (auth, architecture), independent
Decomposition:
Workstream 1: optimize-and-temp (low/medium risk, Tier 2)
- .worktrees/optimize-and-temp, feat/optimize-and-temp
- Coder A: optimize button → review → test → commit
- Coder B: temperature display → review → test → commit
- PR #1
Workstream 2: ai-recommendations (HIGH risk, Tier 1)
- .worktrees/ai-recommendations, feat/ai-recommendations
- Human checkpoint: encryption approach + key storage design
- Coder C: encrypted key CRUD → security review → test → commit
- Coder D: wire recommendations → review → test → commit
- PR #2
Workstream 3: mcp-server (HIGH risk, Tier 1) — or DEFERRED per critic
- Human checkpoint: MCP SDK vs REST, auth model
- .worktrees/mcp-server, feat/mcp-server
- Coder E: MCP implementation → security review → adversarial test → commit
- PR #3
```
### Example: 2 tightly-coupled features
```
User requests: add dark mode toggle + persist theme preference
Analysis:
- Toggle and persistence are tightly coupled (same state, same UX flow)
- Both touch settings page + theme context
Decomposition:
Single workstream: dark-mode (medium risk, Tier 2)
- One worktree, one branch, one PR
- Coder A: toggle + persistence together (they share state)
- Or split if toggle is pure UI and persistence is API: two coder calls
```

146
.config/opencode/tool/megamemory.ts Normal file
View File

@@ -0,0 +1,146 @@
import { tool } from "@opencode-ai/plugin";
const SKILL = `
---
name: megamemory
description: Project knowledge graph — persistent memory across sessions. Use at session start, before tasks (to load context), and after tasks (to record what you built). The graph stores concepts, architecture, decisions, and relationships — written by you, for you.
allowed-tools: "megamemory:*"
---
# Megamemory — Project Knowledge Graph
Your persistent memory of the codebase. You have no implicit memory of this project between sessions, so this graph is your continuity. You write concepts as you work, and you query them before starting tasks.
## When to Use
- **Session start** → You must call \`list_roots\` before beginning work
- **Before any task** → You must call \`understand\` before reading source files for project understanding
- **After any task** → You must call \`create_concept\` / \`update_concept\` / \`link\` to record what you did
- **Refactoring or removing features** → You must call \`remove_concept\` to mark things as gone (with reason)
## Core Principles
1. **Query before work, update after work.** This is required, not optional.
2. **Concepts, not code.** Nodes are features, patterns, decisions — not files or symbols.
3. **Be specific.** Include parameter names, defaults, file paths, rationale.
4. **Keep it shallow.** Max 3 levels deep. Useful beats exhaustive.
## Concept Kinds
\`feature\` | \`module\` | \`pattern\` | \`config\` | \`decision\` | \`component\`
## Relationship Types
- \`depends_on\` — A requires B to function
- \`implements\` — A is the concrete implementation of B
- \`calls\` — A invokes B at runtime
- \`connects_to\` — A and B interact or share data
- \`configured_by\` — A's behavior is controlled by B
## MCP Tools Reference
| Tool | When | What it does |
|---|---|---|
| \`megamemory:understand\` | Before tasks | Semantic search — returns matching concepts with children, edges, parent |
| \`megamemory:create_concept\` | After tasks | Add new concept with summary, kind, edges, file refs |
| \`megamemory:update_concept\` | After tasks | Patch existing concept fields |
| \`megamemory:link\` | After tasks | Create relationship between two concepts |
| \`megamemory:remove_concept\` | On refactor/delete | Soft-delete with reason (history preserved) |
| \`megamemory:list_roots\` | Session start | All top-level concepts with children + stats |
| \`megamemory:list_conflicts\` | After merge | Lists unresolved merge conflicts grouped by merge_group |
| \`megamemory:resolve_conflict\` | During /merge | Resolve a conflict by providing verified, correct content |
`;
export default tool({
description: SKILL,
args: {
action: tool.schema
.enum(["query", "record", "overview", "merge"])
.describe(
"Workflow action: query (before task — understand context), record (after task — create/update/link), overview (session start — list roots), merge (resolve merge conflicts)",
),
query: tool.schema
.string()
.optional()
.describe("Natural language query for the 'query' action"),
concepts: tool.schema
.string()
.optional()
.describe(
"For 'record' action: brief description of what concepts to create/update/link",
),
},
async execute({ action, query, concepts }) {
switch (action) {
case "overview":
return `To get a project overview, call:
1. megamemory:list_roots — Returns all top-level concepts with their children and graph stats.
Use this at the start of every session to orient yourself. If the graph is empty, proceed normally and create concepts as you work.`;
case "query":
if (!query) {
return "Error: query is required for the query action. Describe what you need to understand about the project.";
}
return `To load context for "${query}", call:
1. megamemory:understand — query="${query}"
Returns: matched concepts ranked by relevance, each with:
- summary, why, file_refs
- children (1 level)
- outgoing and incoming edges
- parent context
Use the returned context instead of re-reading source files when possible. If no relevant results come back, proceed normally — the graph may not cover this area yet.`;
case "record":
return `After completing your task, update the knowledge graph:
1. **New concepts** → megamemory:create_concept
- name: human-readable name
- kind: feature | module | pattern | config | decision | component
- summary: specific — include param names, defaults, file paths, behavior
- why: rationale for this design
- parent_id: parent concept slug (for nesting)
- file_refs: relevant file paths + line ranges
- edges: [{to: "concept-id", relation: "depends_on|implements|calls|connects_to|configured_by", description: "why"}]
- created_by_task: what task/prompt created this
2. **Changed concepts** → megamemory:update_concept
- id: the concept slug
- changes: {summary?, why?, file_refs?, name?, kind?}
3. **New relationships** → megamemory:link
- from, to: concept IDs
- relation: depends_on | implements | calls | connects_to | configured_by
- description: why this relationship exists
4. **Removed features** → megamemory:remove_concept
- id: concept to remove
- reason: why it was removed${concepts ? `\n\nContext about what to record: "${concepts}"` : ""}`;
case "merge":
return `To resolve merge conflicts in the knowledge graph:
1. **List conflicts** → megamemory:list_conflicts
- Returns all unresolved conflicts grouped by merge_group
- Each group has competing versions with summaries, file_refs, edges
2. **For each conflict:**
a. Read both versions' summaries, file_refs, and edges
b. Read the actual source files referenced in file_refs to determine what the code ACTUALLY does now
c. Write the correct resolved content based on the current codebase — do NOT just pick a side
3. **Resolve** → megamemory:resolve_conflict
- merge_group: the UUID of the conflict
- resolved: {summary, why?, file_refs?} — the verified, correct content
- reason: what you verified and why this resolution is correct
The goal is accuracy: the resolved concept should describe the code as it actually exists. If referenced files no longer exist, the concept may be outdated — update or remove accordingly.`;
default:
return `Unknown action: ${action}. Use: overview (session start), query (before task), record (after task), merge (resolve conflicts).`;
}
},
});

177
.config/rofi/config.rasi Normal file
View File

@@ -0,0 +1,177 @@
* {
bg-col: #1e1e2e;
bg-col-light: #313244;
border-col: #313244;
selected-col: #313244;
blue: #89b4fa;
fg-col: #cdd6f4;
fg-col2: #f38ba8;
grey: #6c7086;
mauve: #cba6f7;
lavender: #b4befe;
sapphire: #74c7ec;
sky: #89dceb;
teal: #94e2d5;
green: #a6e3a1;
yellow: #f9e2af;
peach: #fab387;
maroon: #eba0ac;
red: #f38ba8;
}
configuration {
modi: "drun,run,window,ssh";
show-icons: true;
display-drun: " ";
display-run: " ";
display-window: " ";
display-ssh: " ";
drun-display-format: "{icon} {name}";
window-format: "{w} {c} {t}";
font: "JetBrainsMono Nerd Font 12";
}
window {
background-color: @bg-col;
border: 2px;
border-color: @lavender;
border-radius: 10px;
width: 600px;
padding: 20px;
}
mainbox {
background-color: transparent;
children: [inputbar, listview];
spacing: 15px;
}
inputbar {
background-color: @bg-col-light;
border-radius: 8px;
padding: 12px 16px;
children: [prompt, entry];
spacing: 12px;
}
prompt {
background-color: transparent;
text-color: @lavender;
font: "JetBrainsMono Nerd Font 14";
}
entry {
background-color: transparent;
text-color: @fg-col;
placeholder: "Search...";
placeholder-color: @grey;
cursor: text;
}
listview {
background-color: transparent;
columns: 1;
lines: 8;
spacing: 8px;
fixed-height: false;
dynamic: true;
}
element {
padding: 10px 16px;
border-radius: 8px;
spacing: 12px;
}
element-icon {
size: 24px;
}
element-text {
text-color: @fg-col;
vertical-align: 0.5;
}
element normal.normal {
background-color: @bg-col;
text-color: @fg-col;
}
element selected.normal {
background-color: @lavender;
text-color: @bg-col;
}
element alternate.normal {
background-color: @bg-col;
text-color: @fg-col;
}
element normal.active {
background-color: @bg-col;
text-color: @green;
}
element selected.active {
background-color: @green;
text-color: @bg-col;
}
element alternate.active {
background-color: @bg-col;
text-color: @green;
}
element normal.urgent {
background-color: @bg-col;
text-color: @red;
}
element selected.urgent {
background-color: @red;
text-color: @bg-col;
}
element alternate.urgent {
background-color: @bg-col;
text-color: @red;
}
scrollbar {
background-color: @bg-col-light;
handle-color: @lavender;
handle-width: 4px;
border-radius: 2px;
}
mode-switcher {
background-color: transparent;
}
button {
background-color: @bg-col-light;
text-color: @fg-col;
padding: 8px 16px;
border-radius: 8px;
}
button selected {
background-color: @lavender;
text-color: @bg-col;
}
message {
background-color: @bg-col-light;
border-radius: 8px;
padding: 12px;
}
textbox {
background-color: transparent;
text-color: @fg-col;
}
error-message {
background-color: @red;
text-color: @bg-col;
}

142
.config/waybar/config Normal file
View File

@@ -0,0 +1,142 @@
{
"layer": "bottom",
"position": "top",
"spacing" : 6,
"modules-left": [
"backlight",
"wireplumber",
"custom/pomodoro",
],
"modules-center": ["clock"],
"modules-right": [
"tray",
"bluetooth",
"temperature",
"cpu",
"memory",
"battery"
],
"hyprland/workspaces": {
"format": "{name}: {icon}",
"format-icons": {
"active": "",
"default": ""
}
},
"bluetooth": {
"format": "󰂲",
"format-on": "{icon}",
"format-off": "{icon}",
"format-connected":"{icon}",
"format-icons":{
"on":"󰂯",
"off": "󰂲",
"connected": "󰂱",
},
"on-click": "blueman-manager",
"tooltip-format-connected":"{device_enumerate}"
},
"custom/music": {
"format": " {}",
"escape": true,
"interval": 5,
"tooltip": false,
"exec": "playerctl metadata --format='{{ artist }} - {{ title }}'",
"on-click": "playerctl play-pause",
"max-length": 50
},
"clock": {
"tooltip": false,
"format": "{:%H:%M - %a,%d}",
"interval": 1
},
"network": {
"format-wifi": "󰤢 {essid}",
"format-ethernet": "󰈀 {ifname}",
"format-disconnected": "󰤠 ",
"interval": 5,
"tooltip-format": "{ipaddr}/{cidr}",
"on-click": "nm-connection-editor",
"max-length": 20
},
"cpu": {
"interval": 1,
"format": " {usage}%",
"on-click": "ghostty -e htop"
},
"memory": {
"interval": 5,
"format": " {percentage}%",
"tooltip-format": "{used:0.1f}G/{total:0.1f}G"
},
"temperature": {
"interval": 5,
"format": "{icon}{temperatureC}°C",
"format-icons": ["󱃃", "󰔏", "󱃂"],
"critical-threshold": 80
},
"custom/uptime": {
"format": "{}",
"format-icon": [""],
"tooltip": false,
"interval": 1600,
"exec": "$HOME/.config/waybar/scripts/uptime.sh"
},
"backlight": {
"format": "{icon} {percent}%",
"format-icons": ["","󰃜", "󰃛", "󰃞","󰃝","󰃟","󰃠"],
"tooltip": false
},
"battery": {
"interval":2,
"states": {
// "good": 95,
"warning": 30,
"critical": 15
},
"format": "{icon} {capacity}%",
"format-full": "{icon} {capacity}%",
"format-charging": " {capacity}%",
"format-plugged": " {capacity}%",
"format-alt": "{icon} {time}",
// "format-good": "", // An empty format will hide the module
// "format-full": "",
"format-icons": ["", "", "", "", ""]
},
"wireplumber": {
"format": "{icon} {volume}%",
"format-muted": "󰝟",
"on-click": "pavucontrol",
"format-icons": ["󰕿", "󰖀", "󰕾"]
},
"custom/lock": {
"tooltip": false,
"on-click": "sh -c '(sleep 0s; hyprlock)' & disown",
"format" : ""
},
"custom/pomodoro": {
"format": "{}",
"return-type": "json",
"exec": "waybar-module-pomodoro --no-work-icons",
"on-click": "waybar-module-pomodoro toggle",
"on-click-right": "$HOME/.config/waybar/scripts/pomodoro-preset.sh",
"on-click-middle": "waybar-module-pomodoro reset",
},
}

33
.config/waybar/scripts/pomodoro-preset.sh Executable file
View File

@@ -0,0 +1,33 @@
#!/usr/bin/env bash
set -euo pipefail
STATE_FILE="/tmp/pomodoro-preset"
if ! command -v waybar-module-pomodoro >/dev/null 2>&1; then
echo "Error: waybar-module-pomodoro is not installed or not in PATH." >&2
exit 1
fi
current="A"
if [[ -f "$STATE_FILE" ]]; then
read -r current < "$STATE_FILE" || current="A"
fi
if [[ "$current" == "A" ]]; then
next="B"
work=50
short=10
long=20
else
next="A"
work=25
short=5
long=15
fi
waybar-module-pomodoro set-work "$work"
waybar-module-pomodoro set-short "$short"
waybar-module-pomodoro set-long "$long"
printf '%s\n' "$next" > "$STATE_FILE"

183
.config/waybar/style.css Normal file
View File

@@ -0,0 +1,183 @@
@define-color foreground #cdd6f4;
@define-color foreground-inactive #6c7086;
@define-color background #1e1e2e;
@define-color surface0 #313244;
@define-color surface1 #45475a;
@define-color lavender #b4befe;
@define-color mauve #cba6f7;
@define-color blue #89b4fa;
@define-color green #a6e3a1;
@define-color yellow #f9e2af;
@define-color peach #fab387;
@define-color red #f38ba8;
* {
font-family: JetBrainsMono Nerd Font;
font-size: 12px;
padding: 0;
margin: 0;
}
#waybar {
color: @foreground;
background-color: @background;
}
#workspaces {
margin: 4px;
padding: 0 4px;
}
#workspaces button {
color: @foreground;
padding-left: 0.7em;
border-radius: 4px;
margin: 2px;
}
#workspaces button.empty {
color: @foreground-inactive;
}
#workspaces button.active {
background-color: @surface1;
color: @foreground;
}
#workspaces button:hover {
background-color: @surface1;
}
#workspaces button.active:hover {
background-color: @surface0;
}
#clock {
color: @foreground;
padding: 0 4px;
margin: 2px;
}
#custom-platform-profile {
padding-left: 4px;
color: @peach;
}
#temperature {
}
#wireplumber {
padding: 0 4px;
}
#wireplumber.muted {
color: @red;
}
#cpu {
padding: 0 4px;
}
#memory {
padding: 0 4px;
}
#temperature {
padding: 0 4px;
}
#temperature.critical {
color: @red;
}
#custom-uptime {
padding: 0 4px;
color: @peach;
}
#pulseaudio {
padding: 0 4px;
}
#backlight {
padding: 0 4px;
}
#custom-pomodoro {
padding: 0 4px;
color: @red;
}
#battery {
padding: 0 4px;
}
#battery.critical {
color: @red;
}
#battery.warning {
color: @yellow;
}
#idle_inhibitor {
padding-right: 1em;
color: @lavender;
}
#idle_inhibitor.activated {
color: @yellow;
}
#language {
padding-right: 1em;
color: @foreground;
}
#network {
padding: 0 4px;
}
#network.disconnected {
color: @red;
}
#bluetooth {
padding: 0 4px;
}
#bluetooth.disabled {
color: @foreground-inactive;
}
#bluetooth.connected {
color: @mauve;
}
#tray {
padding: 0 4px;
}
#tray:hover {
background-color: @surface0;
border-radius: 4px;
}
#tray > .passive {
-gtk-icon-effect: dim;
}
#tray > .needs-attention {
-gtk-icon-effect: highlight;
background-color: @red;
}
tooltip {
background-color: @surface0;
border: 1px solid @lavender;
border-radius: 4px;
}
tooltip label {
color: @foreground;
}

1
.config/zathura/zathurarc Normal file
View File

@@ -0,0 +1 @@
set selection-clipboard clipboard

2
.dmrc Normal file
View File

@@ -0,0 +1,2 @@
[Desktop]
Session=hyprland

11
.gitconfig Normal file
View File

@@ -0,0 +1,11 @@
[credential "https://github.com"]
helper =
helper = !/usr/bin/gh auth git-credential
[credential "https://gist.github.com"]
helper =
helper = !/usr/bin/gh auth git-credential
[user]
email = misc@wiesner.com.br
name = alex
[init]
defaultBranch = main

2
.profile Normal file
View File

@@ -0,0 +1,2 @@
. "$HOME/.local/bin/env"

12
.ssh/config Normal file
View File

@@ -0,0 +1,12 @@
Host raspi-local
HostName 192.168.0.86
User pi
Host raspi
HostName ssh.rwiesner.com
User pi
ProxyCommand cloudflared access ssh --hostname %h
Host prod
HostName 159.195.46.178
User production

7
.ssh/id_ed25519 Normal file
View File

@@ -0,0 +1,7 @@
-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAAAMwAAAAtzc2gtZW
QyNTUxOQAAACB+iRRVGwr8oENymIVrEhYK685Kjeo+ppGodaaInFtTxwAAAJCE8SUghPEl
IAAAAAtzc2gtZWQyNTUxOQAAACB+iRRVGwr8oENymIVrEhYK685Kjeo+ppGodaaInFtTxw
AAAECl1pqdFvP2CV4YtHmzasQd/yJSDf1+1SoUJosbzpEEbn6JFFUbCvygQ3KYhWsSFgrr
zkqN6j6mkah1poicW1PHAAAACWFsZXhAYXJjaAECAwQ=
-----END OPENSSH PRIVATE KEY-----

1
.ssh/id_ed25519.pub Normal file
View File

@@ -0,0 +1 @@
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIH6JFFUbCvygQ3KYhWsSFgrrzkqN6j6mkah1poicW1PH alex@arch

4
.ssh/known_hosts Normal file
View File

@@ -0,0 +1,4 @@
192.168.0.86 ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGNaRHnfPdOx/Ws6Chzp0yXIgklif3wImIL4ERA9qkoI
192.168.0.86 ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCYJ9XPnMjoQlT3m/MLNPnAwTpO+d35+mptpi0iBJ3ySECb4Q6mFnhUL99+zbf5KntqOUW1m16yraQbEVp0tZZkbo5I+5Y8nNATVGcEn+AS5tTgTp09L8litbxNwF3VS4YfGsRTAkCbi954IGexg7ijawH+HeM8HTjJOnbzW23k7LKItTH+5PWAIBfvoUVoheYexAhUHGDfdSaEpkCrqcg+4Uazvgq9dHKgtqvx5PPGawfuJKr2mzmFSz/oOFeISAiP8wkxWfRaKJB7TJWtB4oL7wfHUqCfDORYvNhA7PPnzLtCMxqaMcjq16LW93LP14498SkwOfPjRT7QBVPGG7xUBA8mGOEB13m/7aQOm8nn2yYg4BAviAa9JuDyv0EcY1Pvpx7uP7veAD04rUyyyAD1/pZrpb1C264/8vubVASdr0VH2/o2tGciFDKmI4tENCZntMI6y2ytbPyhrqIpT5wXrwqbKpNAs2PJSt8QEvv/He3mcQ8kphhNKaFvLhI/eSc=
192.168.0.86 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBJjBGU5qutJuNvwuowmjzxLxxHaMwqXg+RaeFM+nKXYWD7BUGin0yhbGUIdsXhREwEQt6qLz8rxQVjKzuYTD5aA=
ssh.rwiesner.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGNaRHnfPdOx/Ws6Chzp0yXIgklif3wImIL4ERA9qkoI

1
.ssh/known_hosts.old Normal file
View File

@@ -0,0 +1 @@
192.168.0.86 ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGNaRHnfPdOx/Ws6Chzp0yXIgklif3wImIL4ERA9qkoI

2
.zshrc Normal file
View File

@@ -0,0 +1,2 @@
. "$HOME/.local/bin/env"