bd daemon sync: 2026-01-12 20:32:06
This commit is contained in:
@@ -14,7 +14,7 @@
|
|||||||
{"id":"nixos-configs-cph","title":"Add Gitea issue tracker integration","description":"## Summary\nAdd Gitea/Forgejo issue tracker integration to beads, following the patterns established by the Linear integration (bidirectional sync) and the GitHub/Jira import examples.\n\n## Context\nThe beads project at ~/src/beads/ already has:\n- **Linear**: Full bidirectional sync in `internal/linear/` (types, client, mapping)\n- **GitHub**: Import-only via `examples/github-import/gh2jsonl.py`\n- **Jira**: Import + partial export via `examples/jira-import/`\n\n## Implementation Structure\nBased on Linear's architecture, create:\n\n```\ninternal/gitea/\n├── types.go # API response types (Issue, Label, User, Repository)\n├── client.go # REST client with pagination, auth, rate limiting\n├── mapping.go # Field conversion (status, priority, labels → beads)\n└── mapping_test.go # Comprehensive mapping tests\n```\n\n## Key Components\n\n### types.go\n- Gitea REST API response structures\n- ClientConfig (baseURL, token, owner, repo)\n- SyncStats/SyncResult types\n\n### client.go\n- `NewClient(baseURL, token string)` constructor\n- `FetchIssues(ctx, state, pageSize)` - paginated fetch\n- `FetchIssuesSince(ctx, since)` - incremental via `updated_at`\n- `CreateIssue(ctx, ...)` / `UpdateIssue(ctx, ...)` - push support\n\n### mapping.go\n- Status mapping: Gitea (open/closed) → Beads (open/in_progress/closed/blocked)\n- Priority inference from labels (Gitea has no native priority)\n- Type inference from labels (bug, feature, etc.)\n- Hash-based ID generation with collision handling\n\n## Gitea API Specifics\n- REST API: `GET /repos/{owner}/{repo}/issues`\n- Auth: `Authorization: token \u003ctoken\u003e` header\n- Pagination: `page` + `limit` params (not cursor-based)\n- Rate limits: Standard HTTP headers\n\n## Phased Approach\n\n**Phase 1 (MVP):** Import-only\n- REST client + types\n- Basic field mapping\n- Script-based JSONL export (like gh2jsonl.py)\n\n**Phase 2:** Bidirectional sync\n- Push support (create/update)\n- Incremental sync via timestamps\n- RPC integration for `bd sync --gitea`\n\n**Phase 3:** Advanced\n- Issue relations/dependencies\n- Auto-import with file watching\n- Configurable mapping via `bd config`\n\n## References\n- Linear integration: `internal/linear/` (best template for bidirectional)\n- GitHub import: `examples/github-import/gh2jsonl.py`\n- Importer core: `internal/importer/importer.go`","status":"in_progress","priority":2,"issue_type":"feature","created_at":"2026-01-12T20:00:24.253907038-08:00","created_by":"johno","updated_at":"2026-01-12T20:18:52.453529482-08:00"}
|
{"id":"nixos-configs-cph","title":"Add Gitea issue tracker integration","description":"## Summary\nAdd Gitea/Forgejo issue tracker integration to beads, following the patterns established by the Linear integration (bidirectional sync) and the GitHub/Jira import examples.\n\n## Context\nThe beads project at ~/src/beads/ already has:\n- **Linear**: Full bidirectional sync in `internal/linear/` (types, client, mapping)\n- **GitHub**: Import-only via `examples/github-import/gh2jsonl.py`\n- **Jira**: Import + partial export via `examples/jira-import/`\n\n## Implementation Structure\nBased on Linear's architecture, create:\n\n```\ninternal/gitea/\n├── types.go # API response types (Issue, Label, User, Repository)\n├── client.go # REST client with pagination, auth, rate limiting\n├── mapping.go # Field conversion (status, priority, labels → beads)\n└── mapping_test.go # Comprehensive mapping tests\n```\n\n## Key Components\n\n### types.go\n- Gitea REST API response structures\n- ClientConfig (baseURL, token, owner, repo)\n- SyncStats/SyncResult types\n\n### client.go\n- `NewClient(baseURL, token string)` constructor\n- `FetchIssues(ctx, state, pageSize)` - paginated fetch\n- `FetchIssuesSince(ctx, since)` - incremental via `updated_at`\n- `CreateIssue(ctx, ...)` / `UpdateIssue(ctx, ...)` - push support\n\n### mapping.go\n- Status mapping: Gitea (open/closed) → Beads (open/in_progress/closed/blocked)\n- Priority inference from labels (Gitea has no native priority)\n- Type inference from labels (bug, feature, etc.)\n- Hash-based ID generation with collision handling\n\n## Gitea API Specifics\n- REST API: `GET /repos/{owner}/{repo}/issues`\n- Auth: `Authorization: token \u003ctoken\u003e` header\n- Pagination: `page` + `limit` params (not cursor-based)\n- Rate limits: Standard HTTP headers\n\n## Phased Approach\n\n**Phase 1 (MVP):** Import-only\n- REST client + types\n- Basic field mapping\n- Script-based JSONL export (like gh2jsonl.py)\n\n**Phase 2:** Bidirectional sync\n- Push support (create/update)\n- Incremental sync via timestamps\n- RPC integration for `bd sync --gitea`\n\n**Phase 3:** Advanced\n- Issue relations/dependencies\n- Auto-import with file watching\n- Configurable mapping via `bd config`\n\n## References\n- Linear integration: `internal/linear/` (best template for bidirectional)\n- GitHub import: `examples/github-import/gh2jsonl.py`\n- Importer core: `internal/importer/importer.go`","status":"in_progress","priority":2,"issue_type":"feature","created_at":"2026-01-12T20:00:24.253907038-08:00","created_by":"johno","updated_at":"2026-01-12T20:18:52.453529482-08:00"}
|
||||||
{"id":"nixos-configs-dew","title":"Evaluate Home-Manager Roles","description":"# Investigation: Home-Manager Roles\n\n## Questions to Answer\n- Is there clean separation from system roles?\n- Are roles reusable across platforms (Darwin/Linux/WSL)?\n- Are option patterns consistent?\n\n## Key Files\n- `home/roles/default.nix` - Home-manager role patterns\n- `home/roles/*/default.nix` - Individual home role definitions\n\n## Approach\n1. Use `/humanlayer:research_codebase_nt` to analyze home role structure\n2. Check for platform-specific vs shared patterns\n3. Use `/humanlayer:create_plan_nt` to plan improvements if needed","status":"closed","priority":2,"issue_type":"task","created_at":"2026-01-10T10:08:24.003251223-08:00","created_by":"johno","updated_at":"2026-01-10T10:11:49.233331206-08:00","closed_at":"2026-01-10T10:11:49.233331206-08:00","close_reason":"# Home-Manager Roles Evaluation Complete\n\n## Overview\nThe home-manager roles structure is well-organized with 21 distinct roles providing modular user configuration management across Linux and Darwin platforms.\n\n## Structure Analysis\n\n### Role Directory Layout\n- home/roles/default.nix - Shared role imports (cross-platform)\n- 21 role subdirectories covering: base, development, desktop, emacs, aerospace, i3+sway, etc.\n- Platform-specific base roles: base-darwin/, base-linux/\n\n## Key Findings\n\n### 1. Clean Separation from System Roles: GOOD\n- Clear namespace: home.roles.* vs roles.* \n- Home roles manage user packages/services, system roles manage OS-level config\n- No duplication of concerns between home and system levels\n\n### 2. Platform Reusability: EXCELLENT\n- Platform segregation via base-* roles\n- base-darwin/ imports: aerospace (macOS tiling)\n- base-linux/ imports: plasma-manager, i3+sway\n- 15 cross-platform shared roles in default.nix\n- Platform guards in aerospace role with isDarwin assertion\n- Conditional config in emacs using stdenv.isDarwin\n\n### 3. Option Patterns: CONSISTENT\nAll roles follow pattern:\n options.home.roles.\u003cname\u003e.enable = mkEnableOption\n config = mkIf cfg.enable { ... }\n\nNotable option extensions:\n- aerospace: leader key, autoraise, ctrlShortcuts, sketchybar\n- i3_sway: browser, extraSharedConfig, extraI3Config, extraSwayConfig\n- development: allowArbitraryClaudeCodeModelSelection\n- launchers: packages list for dynamic wrapper generation\n\n## Strengths\n1. Consistent patterns across all 21 roles\n2. Excellent platform separation via base-linux/base-darwin\n3. Flexible composition with enable flags\n4. Rich options for complex roles (aerospace: 700+ lines, i3_sway: 500+ lines)\n5. Clever solutions: kubectl Bitwarden integration, launchers role\n\n## Minor Observations\n- Gaming role is placeholder\n- openscad-unstable in both office and 3d-printing\n- kubectl duplicates shell functions for bash/zsh\n\n## Conclusion\nThe home-manager roles system demonstrates excellent separation of concerns, cross-platform support, and consistent patterns. No major changes needed - structure is well-designed and maintainable."}
|
{"id":"nixos-configs-dew","title":"Evaluate Home-Manager Roles","description":"# Investigation: Home-Manager Roles\n\n## Questions to Answer\n- Is there clean separation from system roles?\n- Are roles reusable across platforms (Darwin/Linux/WSL)?\n- Are option patterns consistent?\n\n## Key Files\n- `home/roles/default.nix` - Home-manager role patterns\n- `home/roles/*/default.nix` - Individual home role definitions\n\n## Approach\n1. Use `/humanlayer:research_codebase_nt` to analyze home role structure\n2. Check for platform-specific vs shared patterns\n3. Use `/humanlayer:create_plan_nt` to plan improvements if needed","status":"closed","priority":2,"issue_type":"task","created_at":"2026-01-10T10:08:24.003251223-08:00","created_by":"johno","updated_at":"2026-01-10T10:11:49.233331206-08:00","closed_at":"2026-01-10T10:11:49.233331206-08:00","close_reason":"# Home-Manager Roles Evaluation Complete\n\n## Overview\nThe home-manager roles structure is well-organized with 21 distinct roles providing modular user configuration management across Linux and Darwin platforms.\n\n## Structure Analysis\n\n### Role Directory Layout\n- home/roles/default.nix - Shared role imports (cross-platform)\n- 21 role subdirectories covering: base, development, desktop, emacs, aerospace, i3+sway, etc.\n- Platform-specific base roles: base-darwin/, base-linux/\n\n## Key Findings\n\n### 1. Clean Separation from System Roles: GOOD\n- Clear namespace: home.roles.* vs roles.* \n- Home roles manage user packages/services, system roles manage OS-level config\n- No duplication of concerns between home and system levels\n\n### 2. Platform Reusability: EXCELLENT\n- Platform segregation via base-* roles\n- base-darwin/ imports: aerospace (macOS tiling)\n- base-linux/ imports: plasma-manager, i3+sway\n- 15 cross-platform shared roles in default.nix\n- Platform guards in aerospace role with isDarwin assertion\n- Conditional config in emacs using stdenv.isDarwin\n\n### 3. Option Patterns: CONSISTENT\nAll roles follow pattern:\n options.home.roles.\u003cname\u003e.enable = mkEnableOption\n config = mkIf cfg.enable { ... }\n\nNotable option extensions:\n- aerospace: leader key, autoraise, ctrlShortcuts, sketchybar\n- i3_sway: browser, extraSharedConfig, extraI3Config, extraSwayConfig\n- development: allowArbitraryClaudeCodeModelSelection\n- launchers: packages list for dynamic wrapper generation\n\n## Strengths\n1. Consistent patterns across all 21 roles\n2. Excellent platform separation via base-linux/base-darwin\n3. Flexible composition with enable flags\n4. Rich options for complex roles (aerospace: 700+ lines, i3_sway: 500+ lines)\n5. Clever solutions: kubectl Bitwarden integration, launchers role\n\n## Minor Observations\n- Gaming role is placeholder\n- openscad-unstable in both office and 3d-printing\n- kubectl duplicates shell functions for bash/zsh\n\n## Conclusion\nThe home-manager roles system demonstrates excellent separation of concerns, cross-platform support, and consistent patterns. No major changes needed - structure is well-designed and maintainable."}
|
||||||
{"id":"nixos-configs-ek5","title":"Consolidate flake overlay configurations","description":"From Cross-Platform evaluation: The overlay configuration is repeated 3x in flake.nix (nixosModules, nixosModulesUnstable, darwinModules). Could extract to a shared function to reduce duplication.","status":"open","priority":3,"issue_type":"task","created_at":"2026-01-10T10:31:29.045574957-08:00","created_by":"johno","updated_at":"2026-01-10T10:31:29.045574957-08:00"}
|
{"id":"nixos-configs-ek5","title":"Consolidate flake overlay configurations","description":"From Cross-Platform evaluation: The overlay configuration is repeated 3x in flake.nix (nixosModules, nixosModulesUnstable, darwinModules). Could extract to a shared function to reduce duplication.","status":"open","priority":3,"issue_type":"task","created_at":"2026-01-10T10:31:29.045574957-08:00","created_by":"johno","updated_at":"2026-01-10T10:31:29.045574957-08:00"}
|
||||||
{"id":"nixos-configs-f7d","title":"Gitea integration Phase 3: Advanced features","description":"Advanced Gitea integration features.\n\nDeliverables:\n- Issue relations/dependencies sync\n- Configurable mapping via bd config\n- Auto-import with file watching\n- Milestone/project support\n\nParent: nixos-configs-cph","status":"open","priority":4,"issue_type":"task","created_at":"2026-01-12T20:31:54.704415817-08:00","created_by":"johno","updated_at":"2026-01-12T20:31:54.704415817-08:00"}
|
{"id":"nixos-configs-f7d","title":"Gitea integration Phase 3: Advanced features","description":"Advanced Gitea integration features.\n\nDeliverables:\n- Issue relations/dependencies sync\n- Configurable mapping via bd config\n- Auto-import with file watching\n- Milestone/project support\n\nParent: nixos-configs-cph","status":"open","priority":4,"issue_type":"task","created_at":"2026-01-12T20:31:54.704415817-08:00","created_by":"johno","updated_at":"2026-01-12T20:31:54.704415817-08:00","dependencies":[{"issue_id":"nixos-configs-f7d","depends_on_id":"nixos-configs-yrc","type":"blocks","created_at":"2026-01-12T20:32:05.938697843-08:00","created_by":"johno"}]}
|
||||||
{"id":"nixos-configs-fkt","title":"Parameterize hardcoded values in roles","description":"From System Roles evaluation: Several roles have hardcoded values that should be configurable:\n- printing role: hardcoded printer URI (ipp://brother.oglehome/ipp/print)\n- nfs-mounts: hardcoded NFS server IP (10.0.0.43)\n- virtualisation: hardcoded 'johno' for docker group","status":"open","priority":3,"issue_type":"task","created_at":"2026-01-10T10:31:25.104059999-08:00","created_by":"johno","updated_at":"2026-01-10T10:31:25.104059999-08:00"}
|
{"id":"nixos-configs-fkt","title":"Parameterize hardcoded values in roles","description":"From System Roles evaluation: Several roles have hardcoded values that should be configurable:\n- printing role: hardcoded printer URI (ipp://brother.oglehome/ipp/print)\n- nfs-mounts: hardcoded NFS server IP (10.0.0.43)\n- virtualisation: hardcoded 'johno' for docker group","status":"open","priority":3,"issue_type":"task","created_at":"2026-01-10T10:31:25.104059999-08:00","created_by":"johno","updated_at":"2026-01-10T10:31:25.104059999-08:00"}
|
||||||
{"id":"nixos-configs-g47","title":"Gitea integration Phase 1: Import-only Go package","description":"Create internal/gitea/ package with REST client and import support.\n\nTarget: git.johnogle.info\n\nDeliverables:\n- types.go - Gitea API response types\n- client.go - REST client with pagination, auth\n- mapping.go - Field conversion to beads format\n- Import via JSONL generation or direct importer integration\n\nParent: nixos-configs-cph","status":"open","priority":2,"issue_type":"task","created_at":"2026-01-12T20:31:52.854036374-08:00","created_by":"johno","updated_at":"2026-01-12T20:31:52.854036374-08:00"}
|
{"id":"nixos-configs-g47","title":"Gitea integration Phase 1: Import-only Go package","description":"Create internal/gitea/ package with REST client and import support.\n\nTarget: git.johnogle.info\n\nDeliverables:\n- types.go - Gitea API response types\n- client.go - REST client with pagination, auth\n- mapping.go - Field conversion to beads format\n- Import via JSONL generation or direct importer integration\n\nParent: nixos-configs-cph","status":"open","priority":2,"issue_type":"task","created_at":"2026-01-12T20:31:52.854036374-08:00","created_by":"johno","updated_at":"2026-01-12T20:31:52.854036374-08:00"}
|
||||||
{"id":"nixos-configs-geh","title":"Evaluate Scripts \u0026 Utilities","description":"# Investigation: Scripts \u0026 Utilities\n\n## Questions to Answer\n- Are flake apps organized?\n- Are there automation opportunities?\n- Are scripts discoverable and documented?\n\n## Key Files\n- Flake apps definitions\n- Shell scripts in the repo\n- Utility modules\n\n## Approach\n1. Use `/humanlayer:research_codebase_nt` to analyze scripts and utilities\n2. Identify missing automation opportunities\n3. Use `/humanlayer:create_plan_nt` to plan improvements","status":"closed","priority":2,"issue_type":"task","created_at":"2026-01-10T10:08:26.9906695-08:00","created_by":"johno","updated_at":"2026-01-10T10:11:53.187286416-08:00","closed_at":"2026-01-10T10:11:53.187286416-08:00","close_reason":"# Scripts \u0026 Utilities Evaluation\n\n## Summary\nThe NixOS config repository has a well-organized scripts and utilities system with good practices in place.\n\n## Flake Apps (4 available apps)\nAll apps defined in flake.nix, cross-platform (x86_64-linux, aarch64-linux, aarch64-darwin):\n- update-doomemacs: Updates DoomEmacs to latest commit with SHA256 refresh\n- update-claude-code: Updates claude-code package from Homebrew cask (supports --dry-run)\n- rotate-wallpaper: Cycles through wallpaper index\n- upgrade: Meta-script updating flake + doom + claude + wallpaper\n\n### Architecture Strengths\n- Uses writeShellScriptBin with explicit dependency paths via makeBinPath\n- Common dependencies (curl, jq, nix, git, sed, grep, coreutils, gawk) properly managed\n- All scripts use set -euo pipefail for safety\n\n## Standalone Scripts (2 root-level)\n- bootstrap.sh: Initial system setup from remote flake\n- build-liveusb.sh: Builds live USB ISO\n\n## Custom Packages (/packages/) - 5 packages\n1. claude-code - Multi-platform binary distribution with GCS URLs\n2. tea-rbw - Wrapper around tea integrating with rbw for auth\n3. app-launcher-server - Python HTTP server for launching allowlisted apps\n4. vulkan-hdr-layer - HDR graphics layer\n5. perles - Go-based TUI for Beads issue tracking\n\n## Recommendations\nMedium Priority:\n- Add help flags to all flake apps for consistency\n- Consider adding nix run .#help app listing all available apps\n\nLow Priority:\n- Move bootstrap.sh and build-liveusb.sh to flake apps\n- Add comments to packages/default.nix describing each package\n\n## Missing Automation Opportunities\n1. No auto-update mechanism (could add CI job or systemd timer)\n2. No pre-commit hooks for Nix syntax validation\n3. No flake.lock update notifications\n\n## Conclusion\nWell-designed scripts/utilities system using good Nix idioms. The flake apps pattern provides cross-platform consistency. Main gap is documentation/discoverability (minor for personal config). No blocking issues."}
|
{"id":"nixos-configs-geh","title":"Evaluate Scripts \u0026 Utilities","description":"# Investigation: Scripts \u0026 Utilities\n\n## Questions to Answer\n- Are flake apps organized?\n- Are there automation opportunities?\n- Are scripts discoverable and documented?\n\n## Key Files\n- Flake apps definitions\n- Shell scripts in the repo\n- Utility modules\n\n## Approach\n1. Use `/humanlayer:research_codebase_nt` to analyze scripts and utilities\n2. Identify missing automation opportunities\n3. Use `/humanlayer:create_plan_nt` to plan improvements","status":"closed","priority":2,"issue_type":"task","created_at":"2026-01-10T10:08:26.9906695-08:00","created_by":"johno","updated_at":"2026-01-10T10:11:53.187286416-08:00","closed_at":"2026-01-10T10:11:53.187286416-08:00","close_reason":"# Scripts \u0026 Utilities Evaluation\n\n## Summary\nThe NixOS config repository has a well-organized scripts and utilities system with good practices in place.\n\n## Flake Apps (4 available apps)\nAll apps defined in flake.nix, cross-platform (x86_64-linux, aarch64-linux, aarch64-darwin):\n- update-doomemacs: Updates DoomEmacs to latest commit with SHA256 refresh\n- update-claude-code: Updates claude-code package from Homebrew cask (supports --dry-run)\n- rotate-wallpaper: Cycles through wallpaper index\n- upgrade: Meta-script updating flake + doom + claude + wallpaper\n\n### Architecture Strengths\n- Uses writeShellScriptBin with explicit dependency paths via makeBinPath\n- Common dependencies (curl, jq, nix, git, sed, grep, coreutils, gawk) properly managed\n- All scripts use set -euo pipefail for safety\n\n## Standalone Scripts (2 root-level)\n- bootstrap.sh: Initial system setup from remote flake\n- build-liveusb.sh: Builds live USB ISO\n\n## Custom Packages (/packages/) - 5 packages\n1. claude-code - Multi-platform binary distribution with GCS URLs\n2. tea-rbw - Wrapper around tea integrating with rbw for auth\n3. app-launcher-server - Python HTTP server for launching allowlisted apps\n4. vulkan-hdr-layer - HDR graphics layer\n5. perles - Go-based TUI for Beads issue tracking\n\n## Recommendations\nMedium Priority:\n- Add help flags to all flake apps for consistency\n- Consider adding nix run .#help app listing all available apps\n\nLow Priority:\n- Move bootstrap.sh and build-liveusb.sh to flake apps\n- Add comments to packages/default.nix describing each package\n\n## Missing Automation Opportunities\n1. No auto-update mechanism (could add CI job or systemd timer)\n2. No pre-commit hooks for Nix syntax validation\n3. No flake.lock update notifications\n\n## Conclusion\nWell-designed scripts/utilities system using good Nix idioms. The flake apps pattern provides cross-platform consistency. Main gap is documentation/discoverability (minor for personal config). No blocking issues."}
|
||||||
@@ -30,4 +30,4 @@
|
|||||||
{"id":"nixos-configs-und","title":"Evaluate Custom Packages","description":"# Investigation: Custom Packages\n\n## Questions to Answer\n- Are packages well-structured?\n- Is overlay usage optimal?\n- Are packages up-to-date with nixpkgs conventions?\n\n## Key Files\n- `packages/default.nix` - Custom package overlay\n- `packages/*/default.nix` - Individual package definitions\n\n## Approach\n1. Use `/humanlayer:research_codebase_nt` to analyze package structure\n2. Check overlay patterns and composition\n3. Use `/humanlayer:create_plan_nt` to plan improvements if needed","status":"closed","priority":2,"issue_type":"task","created_at":"2026-01-10T10:08:25.566312823-08:00","created_by":"johno","updated_at":"2026-01-10T10:11:22.107817076-08:00","closed_at":"2026-01-10T10:11:22.107817076-08:00","close_reason":"# Custom Packages Evaluation Complete\n\n## Overview\nThe nixos-configs repository contains 5 custom packages, all managed through a single `packages/default.nix` file that exposes them via `pkgs.custom.*` overlay.\n\n## Package-by-Package Analysis\n\n### 1. claude-code (Well-Structured)\n- **Purpose**: Fetches Claude Code CLI directly from Google Cloud Storage, bypassing npm registry (needed for corporate network restrictions)\n- **Structure**: Excellent - uses `stdenv.mkDerivation` with proper multi-platform support (4 platforms)\n- **Update mechanism**: Has automated `update.sh` script that fetches version/hashes from Homebrew cask - very well designed\n- **Documentation**: Includes comprehensive README.md\n- **Usage**: Exposed via overlay to `pkgs.unstable.claude-code` for Darwin machines\n- **Note**: Also has an unused `npm.nix` with placeholder hash - appears to be abandoned attempt\n\n### 2. vulkan-hdr-layer (Well-Structured)\n- **Purpose**: Vulkan layer for HDR support\n- **Structure**: Proper `stdenv.mkDerivation` with meson build system\n- **Issue**: Uses commit hash version `63d2eec` (unstable version) - consider using tagged releases\n- **Note**: Not currently used anywhere in the configuration (orphaned package?)\n\n### 3. tea-rbw (Simple Wrapper)\n- **Purpose**: Wrapper around `tea` (Gitea CLI) that integrates with rbw (Bitwarden CLI) for authentication\n- **Structure**: Simple `writeShellScriptBin` - appropriate for this use case\n- **Usage**: Used in `home/roles/development/default.nix`\n\n### 4. app-launcher-server (Simple Wrapper)\n- **Purpose**: HTTP server for launching allowlisted applications (Firefox, Kodi)\n- **Structure**: Python script with `writeShellScriptBin` wrapper - clean design\n- **Usage**: Used in `roles/kodi/default.nix` for media center control\n\n### 5. perles (Well-Structured)\n- **Purpose**: TUI for Beads issue tracking system\n- **Structure**: Proper `buildGoModule` with GitHub fetch\n- **Issue**: Uses `rev = \"main\"` instead of pinned commit - can cause reproducibility issues\n- **Usage**: Used in `home/roles/development/default.nix`\n\n## Overlay Integration\nPackages are exposed via overlay in flake.nix:\n```nix\ncustom = prev.callPackage ./packages {};\n```\nThis is a clean, standard pattern.\n\n## Observations\n\n### Strengths\n1. Single entry point (`packages/default.nix`) for all custom packages\n2. Proper use of `callPackage` idiom\n3. Good variety of build patterns (stdenv, buildGoModule, writeShellScriptBin)\n4. Excellent automated update script for claude-code\n5. Proper meta attributes on most packages\n\n### Issues/Recommendations\n1. **vulkan-hdr-layer appears unused** - consider removing if not needed\n2. **perles uses `rev = \"main\"`** - should pin to specific commit for reproducibility\n3. **npm.nix is unused** - leftover file in claude-code directory\n4. **Missing maintainers** - all packages have empty maintainers list\n5. **vulkan-hdr-layer uses unstable version** - uses commit hash, not tagged release\n\n## Nixpkgs Convention Compliance\n- Package naming follows conventions\n- Meta attributes present\n- Uses appropriate build helpers\n- Overlay pattern is idiomatic\n- Could benefit from adding tests for some packages"}
|
{"id":"nixos-configs-und","title":"Evaluate Custom Packages","description":"# Investigation: Custom Packages\n\n## Questions to Answer\n- Are packages well-structured?\n- Is overlay usage optimal?\n- Are packages up-to-date with nixpkgs conventions?\n\n## Key Files\n- `packages/default.nix` - Custom package overlay\n- `packages/*/default.nix` - Individual package definitions\n\n## Approach\n1. Use `/humanlayer:research_codebase_nt` to analyze package structure\n2. Check overlay patterns and composition\n3. Use `/humanlayer:create_plan_nt` to plan improvements if needed","status":"closed","priority":2,"issue_type":"task","created_at":"2026-01-10T10:08:25.566312823-08:00","created_by":"johno","updated_at":"2026-01-10T10:11:22.107817076-08:00","closed_at":"2026-01-10T10:11:22.107817076-08:00","close_reason":"# Custom Packages Evaluation Complete\n\n## Overview\nThe nixos-configs repository contains 5 custom packages, all managed through a single `packages/default.nix` file that exposes them via `pkgs.custom.*` overlay.\n\n## Package-by-Package Analysis\n\n### 1. claude-code (Well-Structured)\n- **Purpose**: Fetches Claude Code CLI directly from Google Cloud Storage, bypassing npm registry (needed for corporate network restrictions)\n- **Structure**: Excellent - uses `stdenv.mkDerivation` with proper multi-platform support (4 platforms)\n- **Update mechanism**: Has automated `update.sh` script that fetches version/hashes from Homebrew cask - very well designed\n- **Documentation**: Includes comprehensive README.md\n- **Usage**: Exposed via overlay to `pkgs.unstable.claude-code` for Darwin machines\n- **Note**: Also has an unused `npm.nix` with placeholder hash - appears to be abandoned attempt\n\n### 2. vulkan-hdr-layer (Well-Structured)\n- **Purpose**: Vulkan layer for HDR support\n- **Structure**: Proper `stdenv.mkDerivation` with meson build system\n- **Issue**: Uses commit hash version `63d2eec` (unstable version) - consider using tagged releases\n- **Note**: Not currently used anywhere in the configuration (orphaned package?)\n\n### 3. tea-rbw (Simple Wrapper)\n- **Purpose**: Wrapper around `tea` (Gitea CLI) that integrates with rbw (Bitwarden CLI) for authentication\n- **Structure**: Simple `writeShellScriptBin` - appropriate for this use case\n- **Usage**: Used in `home/roles/development/default.nix`\n\n### 4. app-launcher-server (Simple Wrapper)\n- **Purpose**: HTTP server for launching allowlisted applications (Firefox, Kodi)\n- **Structure**: Python script with `writeShellScriptBin` wrapper - clean design\n- **Usage**: Used in `roles/kodi/default.nix` for media center control\n\n### 5. perles (Well-Structured)\n- **Purpose**: TUI for Beads issue tracking system\n- **Structure**: Proper `buildGoModule` with GitHub fetch\n- **Issue**: Uses `rev = \"main\"` instead of pinned commit - can cause reproducibility issues\n- **Usage**: Used in `home/roles/development/default.nix`\n\n## Overlay Integration\nPackages are exposed via overlay in flake.nix:\n```nix\ncustom = prev.callPackage ./packages {};\n```\nThis is a clean, standard pattern.\n\n## Observations\n\n### Strengths\n1. Single entry point (`packages/default.nix`) for all custom packages\n2. Proper use of `callPackage` idiom\n3. Good variety of build patterns (stdenv, buildGoModule, writeShellScriptBin)\n4. Excellent automated update script for claude-code\n5. Proper meta attributes on most packages\n\n### Issues/Recommendations\n1. **vulkan-hdr-layer appears unused** - consider removing if not needed\n2. **perles uses `rev = \"main\"`** - should pin to specific commit for reproducibility\n3. **npm.nix is unused** - leftover file in claude-code directory\n4. **Missing maintainers** - all packages have empty maintainers list\n5. **vulkan-hdr-layer uses unstable version** - uses commit hash, not tagged release\n\n## Nixpkgs Convention Compliance\n- Package naming follows conventions\n- Meta attributes present\n- Uses appropriate build helpers\n- Overlay pattern is idiomatic\n- Could benefit from adding tests for some packages"}
|
||||||
{"id":"nixos-configs-v2v","title":"Pin perles package to specific commit","description":"From Custom Packages evaluation: perles in packages/perles/default.nix uses rev = 'main' instead of a pinned commit. This breaks reproducibility. Should pin to a specific commit hash.","status":"open","priority":2,"issue_type":"bug","created_at":"2026-01-10T10:31:27.624760234-08:00","created_by":"johno","updated_at":"2026-01-10T10:31:27.624760234-08:00"}
|
{"id":"nixos-configs-v2v","title":"Pin perles package to specific commit","description":"From Custom Packages evaluation: perles in packages/perles/default.nix uses rev = 'main' instead of a pinned commit. This breaks reproducibility. Should pin to a specific commit hash.","status":"open","priority":2,"issue_type":"bug","created_at":"2026-01-10T10:31:27.624760234-08:00","created_by":"johno","updated_at":"2026-01-10T10:31:27.624760234-08:00"}
|
||||||
{"id":"nixos-configs-vru","title":"Add skill for responding to Gitea PR review comments","description":"## Problem\n\nWhen responding to PR review comments on Gitea/Forgejo, the REST API (`/api/v1/...`) does not support replying directly to review comment threads. Using `tea comment` or the API creates new top-level comments instead of inline thread replies.\n\n## Discovery\n\nThe web UI uses a different endpoint that supports replies:\n\n```\nPOST /pulls/{id}/files/reviews/comments\nContent-Type: multipart/form-data\n```\n\nKey form fields:\n- `reply`: Review ID to reply to (e.g., `2`)\n- `content`: The reply message\n- `path`: File path (e.g., `home/roles/development/default.nix`)\n- `line`: Line number\n- `side`: `proposed` or `original`\n- `single_review`: `true`\n- `origin`: `timeline`\n- `_csrf`: CSRF token (required)\n\nAuthentication requires session cookies, not API token.\n\n## Proposed Solution\n\nCreate a Claude skill that can:\n1. Fetch PR review comments via the REST API\n2. Authenticate via browser session or find alternative auth method\n3. Post inline replies to review comment threads using the web endpoint\n\n### Options to explore:\n1. **Session extraction**: Get cookies from browser or `tea` config\n2. **Headless browser**: Use playwright/puppeteer to automate web UI\n3. **CSRF flow**: Login via API, get CSRF token, then use web endpoint\n4. **tea enhancement**: Check if `tea` CLI has undocumented reply support\n\n## API Reference\n\nGet reviews:\n```bash\ncurl -H \"Authorization: token $TOKEN\" \\\n \"https://git.johnogle.info/api/v1/repos/{owner}/{repo}/pulls/{id}/reviews\"\n```\n\nGet review comments:\n```bash\ncurl -H \"Authorization: token $TOKEN\" \\\n \"https://git.johnogle.info/api/v1/repos/{owner}/{repo}/pulls/{id}/reviews/{review_id}/comments\"\n```\n\n## Acceptance Criteria\n\n- [ ] Skill can read PR review comments given a PR number\n- [ ] Skill can post inline replies to specific review comment threads\n- [ ] Works with Gitea/Forgejo instances (git.johnogle.info)\n- [ ] Handles authentication securely","status":"open","priority":2,"issue_type":"feature","created_at":"2026-01-10T11:29:18.493043744-08:00","created_by":"johno","updated_at":"2026-01-10T11:29:32.03825767-08:00"}
|
{"id":"nixos-configs-vru","title":"Add skill for responding to Gitea PR review comments","description":"## Problem\n\nWhen responding to PR review comments on Gitea/Forgejo, the REST API (`/api/v1/...`) does not support replying directly to review comment threads. Using `tea comment` or the API creates new top-level comments instead of inline thread replies.\n\n## Discovery\n\nThe web UI uses a different endpoint that supports replies:\n\n```\nPOST /pulls/{id}/files/reviews/comments\nContent-Type: multipart/form-data\n```\n\nKey form fields:\n- `reply`: Review ID to reply to (e.g., `2`)\n- `content`: The reply message\n- `path`: File path (e.g., `home/roles/development/default.nix`)\n- `line`: Line number\n- `side`: `proposed` or `original`\n- `single_review`: `true`\n- `origin`: `timeline`\n- `_csrf`: CSRF token (required)\n\nAuthentication requires session cookies, not API token.\n\n## Proposed Solution\n\nCreate a Claude skill that can:\n1. Fetch PR review comments via the REST API\n2. Authenticate via browser session or find alternative auth method\n3. Post inline replies to review comment threads using the web endpoint\n\n### Options to explore:\n1. **Session extraction**: Get cookies from browser or `tea` config\n2. **Headless browser**: Use playwright/puppeteer to automate web UI\n3. **CSRF flow**: Login via API, get CSRF token, then use web endpoint\n4. **tea enhancement**: Check if `tea` CLI has undocumented reply support\n\n## API Reference\n\nGet reviews:\n```bash\ncurl -H \"Authorization: token $TOKEN\" \\\n \"https://git.johnogle.info/api/v1/repos/{owner}/{repo}/pulls/{id}/reviews\"\n```\n\nGet review comments:\n```bash\ncurl -H \"Authorization: token $TOKEN\" \\\n \"https://git.johnogle.info/api/v1/repos/{owner}/{repo}/pulls/{id}/reviews/{review_id}/comments\"\n```\n\n## Acceptance Criteria\n\n- [ ] Skill can read PR review comments given a PR number\n- [ ] Skill can post inline replies to specific review comment threads\n- [ ] Works with Gitea/Forgejo instances (git.johnogle.info)\n- [ ] Handles authentication securely","status":"open","priority":2,"issue_type":"feature","created_at":"2026-01-10T11:29:18.493043744-08:00","created_by":"johno","updated_at":"2026-01-10T11:29:32.03825767-08:00"}
|
||||||
{"id":"nixos-configs-yrc","title":"Gitea integration Phase 2: Bidirectional sync","description":"Add push support to Gitea integration.\n\nDeliverables:\n- CreateIssue/UpdateIssue methods in client.go\n- Conflict detection and resolution\n- bd sync --gitea integration\n- Incremental sync via updated_at filtering\n\nParent: nixos-configs-cph","status":"open","priority":3,"issue_type":"task","created_at":"2026-01-12T20:31:53.714748854-08:00","created_by":"johno","updated_at":"2026-01-12T20:31:53.714748854-08:00"}
|
{"id":"nixos-configs-yrc","title":"Gitea integration Phase 2: Bidirectional sync","description":"Add push support to Gitea integration.\n\nDeliverables:\n- CreateIssue/UpdateIssue methods in client.go\n- Conflict detection and resolution\n- bd sync --gitea integration\n- Incremental sync via updated_at filtering\n\nParent: nixos-configs-cph","status":"open","priority":3,"issue_type":"task","created_at":"2026-01-12T20:31:53.714748854-08:00","created_by":"johno","updated_at":"2026-01-12T20:31:53.714748854-08:00","dependencies":[{"issue_id":"nixos-configs-yrc","depends_on_id":"nixos-configs-g47","type":"blocks","created_at":"2026-01-12T20:32:05.872628288-08:00","created_by":"johno"}]}
|
||||||
|
|||||||
Reference in New Issue
Block a user