javi-forge 0.1.0

package/templates/global/copilot-instructions/sdd-orchestrator.instructions.md

@@ -0,0 +1,37 @@
+---
+applyTo: "**"
+---
+
+# Spec-Driven Development (SDD) Orchestrator
+
+You are the ORCHESTRATOR for Spec-Driven Development. You coordinate the SDD workflow by launching specialized sub-agents. Your job is to STAY LIGHTWEIGHT — delegate all heavy work to sub-agents and only track state and user decisions.
+
+## Operating Mode
+- **Delegate-only**: You NEVER execute phase work inline.
+- If work requires analysis, design, planning, implementation, verification, or migration, ALWAYS launch a sub-agent.
+
+## SDD Commands
+| Command | Action | Skill |
+|---------|--------|-------|
+| `/sdd:init` | Bootstrap openspec/ | sdd-init |
+| `/sdd:explore <topic>` | Think through idea | sdd-explore |
+| `/sdd:new <name>` | Start new change | sdd-explore → sdd-propose |
+| `/sdd:continue [name]` | Next artifact in chain | sdd-spec / sdd-design / sdd-tasks |
+| `/sdd:ff [name]` | Fast-forward planning | propose → spec → design → tasks |
+| `/sdd:apply [name]` | Implement tasks | sdd-apply |
+| `/sdd:verify [name]` | Validate implementation | sdd-verify |
+| `/sdd:archive [name]` | Sync specs + archive | sdd-archive |
+
+## Dependency Graph
+```
+proposal → specs ──→ tasks → apply → verify → archive
+              ↕
+           design
+```
+
+## Orchestrator Rules
+1. NEVER read source code directly — sub-agents do that
+2. NEVER write implementation code — sdd-apply does that
+3. ONLY: track state, present summaries, ask for approval, launch sub-agents
+4. Between sub-agent calls, ALWAYS show what was done and ask to proceed
+5. Keep context MINIMAL — pass file paths, not file contents

package/templates/global/gemini-commands/cleanup.toml

@@ -0,0 +1,20 @@
+description = "Clean up code: fix lint issues, improve readability, remove smells"
+prompt = """
+Clean up code in: {{args}}
+
+Focus areas:
+1. Fix lint/formatting issues
+2. Simplify overly complex expressions
+3. Improve variable/function naming for clarity
+4. Remove code smells (long methods, deep nesting, magic numbers)
+5. Extract constants for magic values
+6. Simplify conditional logic (guard clauses, early returns)
+7. Remove unnecessary comments (code should be self-documenting)
+
+Rules:
+- Do NOT change behavior — cleanup only
+- Do NOT add new features or refactor architecture
+- Run tests after cleanup to verify nothing broke
+- Keep changes focused — one type of cleanup per commit
+- Commit with: refactor: clean up <scope>
+"""

package/templates/global/gemini-commands/commit.toml

@@ -0,0 +1,15 @@
+description = "Create a conventional commit from staged changes"
+prompt = """
+Create a git commit from the currently staged changes.
+
+Process:
+1. Run `git diff --cached` to see staged changes
+2. Analyze the nature of the changes (feature, fix, refactor, docs, test, chore)
+3. Draft a Conventional Commit message: type(scope): description
+4. Keep subject line under 72 characters, imperative mood
+5. Add body if changes are complex (blank line after subject)
+6. NEVER add Co-Authored-By or AI attribution
+7. Show the commit message for approval before committing
+
+If no changes are staged, show `git status` and suggest what to stage.
+"""

package/templates/global/gemini-commands/dead-code.toml

@@ -0,0 +1,22 @@
+description = "Identify and remove dead code"
+prompt = """
+Identify and safely remove dead code in: {{args}}
+
+Types of dead code:
+- Functions/methods never called
+- Variables declared but never read
+- Unreachable code branches
+- Unused imports
+- Feature flags always true/false
+- Code after return/throw
+
+Safe process:
+1. Identify candidate code to remove
+2. Search ALL usages in the codebase (exhaustive grep)
+3. Verify it's not used via reflection, dynamic imports, or external config
+4. Remove the code
+5. Run the full test suite
+6. If tests pass: commit 'refactor: remove dead code in X'
+
+Caution: Some 'dead code' is intentional (lifecycle hooks, dynamically registered handlers). Verify before removing.
+"""

package/templates/global/gemini-commands/plan.toml

@@ -0,0 +1,30 @@
+description = "Create an implementation plan for a feature or change"
+prompt = """
+Create an implementation plan for: {{args}}
+
+Process:
+1. Understand the requirement — ask clarifying questions if ambiguous
+2. Explore the codebase to understand current architecture and patterns
+3. Identify affected files and components
+4. Design the approach with trade-offs considered
+5. Break down into ordered implementation steps
+6. Identify risks and edge cases
+
+Output format:
+## Goal
+(1-2 sentences)
+
+## Affected Files
+(list with brief description of changes)
+
+## Implementation Steps
+(numbered, ordered by dependency)
+
+## Risks & Edge Cases
+(what could go wrong)
+
+## Testing Strategy
+(how to verify the change works)
+
+Do NOT start implementing — just plan. Ask for approval before proceeding.
+"""

package/templates/global/gemini-commands/review.toml

@@ -0,0 +1,17 @@
+description = "Review code changes for quality, security, and best practices"
+prompt = """
+Review code changes in: {{args}}
+
+If no path specified, review unstaged changes (`git diff`).
+
+Review checklist:
+1. **Security**: OWASP top 10, injection, XSS, secrets in code
+2. **Logic**: Edge cases, off-by-one, null handling, race conditions
+3. **Performance**: N+1 queries, unnecessary allocations, missing indexes
+4. **Readability**: Naming, complexity, dead code, unclear intent
+5. **Testing**: Missing test coverage for new/changed behavior
+6. **Architecture**: SOLID violations, tight coupling, wrong abstraction level
+
+Format: List issues by severity (critical > warning > suggestion).
+For each issue: file:line, description, suggested fix.
+"""

package/templates/global/gemini-commands/sdd-apply.toml

@@ -0,0 +1,22 @@
+description = "Implement SDD tasks following specs and design"
+prompt = """
+Implement SDD tasks for: {{args}}
+
+Process:
+1. Read the task list from the current SDD change
+2. For each task (in order):
+   a. Read the relevant spec and design sections
+   b. Implement the code changes
+   c. Run tests to verify
+   d. Commit with conventional commit message
+3. Mark each task as completed after successful implementation
+
+Rules:
+- Follow the spec and design exactly — do not deviate
+- One task = one commit (atomic changes)
+- Run tests after EACH task
+- If a task is blocked, report the blocker and skip to the next
+- If you discover something not covered by the spec, stop and ask
+
+Show progress after each task is completed.
+"""

package/templates/global/gemini-commands/sdd-ff.toml

@@ -0,0 +1,14 @@
+description = "Fast-forward SDD: create all planning artifacts (proposal, spec, design, tasks)"
+prompt = """
+Fast-forward SDD planning for: {{args}}
+
+Execute ALL planning phases in sequence:
+
+1. PROPOSE — Create proposal.md (intent, scope, approach, risks)
+2. SPEC — Write specifications (requirements, scenarios, acceptance criteria)
+3. DESIGN — Technical design (architecture decisions, patterns, implementation approach)
+4. TASKS — Break down into numbered task checklist with phases and dependencies
+
+Show a complete summary of ALL artifacts after they are done.
+Ask user to review before proceeding to implementation.
+"""

package/templates/global/gemini-commands/sdd-new.toml

@@ -0,0 +1,21 @@
+description = "Start a new SDD change: explore the idea and create a proposal"
+prompt = """
+Start a new SDD change for: {{args}}
+
+Execute the EXPLORE + PROPOSE phases:
+
+1. EXPLORE — Investigate the idea
+   - Understand the current codebase state relevant to this change
+   - Identify affected components and dependencies
+   - List risks, unknowns, and questions
+   - Scope: what's in, what's out
+
+2. PROPOSE — Create proposal
+   - Intent: what and why
+   - Scope: files/components affected
+   - Approach: how to implement (with alternatives considered)
+   - Risks: what could go wrong
+   - Acceptance criteria: how to verify success
+
+Show the proposal summary and ask for approval before proceeding to specs.
+"""

package/templates/global/gemini-commands/sdd-verify.toml

@@ -0,0 +1,21 @@
+description = "Validate SDD implementation against specs and acceptance criteria"
+prompt = """
+Verify SDD implementation for: {{args}}
+
+Validation checklist:
+1. **Acceptance Criteria** — Check each criterion from the spec
+2. **Test Coverage** — Verify tests exist for all specified behaviors
+3. **Design Compliance** — Implementation follows the design document
+4. **Edge Cases** — Scenarios from the spec are handled
+5. **No Scope Creep** — Nothing was added beyond the spec
+6. **No Regressions** — Existing tests still pass
+
+Process:
+1. Read the spec and design documents
+2. Compare implementation against each requirement
+3. Run the full test suite
+4. Report: PASS/FAIL for each criterion
+5. List any deviations or gaps found
+
+Output a verification report with clear pass/fail status.
+"""

package/templates/global/gemini-commands/tdd.toml

@@ -0,0 +1,26 @@
+description = "Implement a feature using Test-Driven Development"
+prompt = """
+Implement using TDD: {{args}}
+
+Follow the Red-Green-Refactor cycle strictly:
+
+1. **RED** — Write a failing test first
+   - Test the expected behavior, not implementation details
+   - Run the test to confirm it FAILS (important!)
+
+2. **GREEN** — Write the MINIMUM code to make the test pass
+   - No extra features, no premature optimization
+   - Run the test to confirm it PASSES
+
+3. **REFACTOR** — Clean up while tests stay green
+   - Remove duplication, improve naming, simplify
+   - Run tests after each refactoring step
+
+Repeat the cycle for each behavior/requirement.
+
+Rules:
+- Never write production code without a failing test first
+- Each cycle should be small (1 behavior = 1 test = 1 cycle)
+- Show the test BEFORE the implementation
+- Run tests after EVERY step
+"""

package/templates/global/gemini-settings.json

@@ -0,0 +1,8 @@
+{
+  "context": {
+    "fileName": ["GEMINI.md", "AGENTS.md"]
+  },
+  "output": {
+    "codeStyle": "fenced"
+  }
+}

package/templates/global/opencode-config.json

@@ -0,0 +1,44 @@
+{
+  "$schema": "https://opencode.ai/config.json",
+  "theme": "gentleman",
+  "autoupdate": true,
+  "permission": {
+    "bash": {
+      "*": "allow",
+      "git commit *": "ask",
+      "git push *": "ask",
+      "git push": "ask",
+      "git push --force *": "ask",
+      "git rebase *": "ask",
+      "git reset --hard *": "ask"
+    },
+    "read": {
+      "*": "allow",
+      "*.env": "deny",
+      "*.env.*": "deny",
+      "**/.env": "deny",
+      "**/.env.*": "deny",
+      "**/secrets/**": "deny",
+      "**/credentials.json": "deny"
+    }
+  },
+  "mcp": {
+    "context7": {
+      "type": "remote",
+      "url": "https://mcp.context7.com/mcp",
+      "enabled": true
+    }
+  },
+  "agent": {
+    "sdd-orchestrator": {
+      "mode": "all",
+      "description": "Spec-Driven Development delegate-only orchestrator",
+      "prompt": "You are the ORCHESTRATOR for Spec-Driven Development. You coordinate the SDD workflow by launching specialized sub-agents. Your job is to STAY LIGHTWEIGHT — delegate all heavy work to sub-agents and only track state and user decisions.\n\n## Operating Mode\n- Delegate-only: You NEVER execute phase work inline.\n- If work requires analysis, design, planning, implementation, verification, or migration, ALWAYS launch a sub-agent.\n\n## SDD Commands\n| Command | Action |\n|---------|--------|\n| /sdd:init | Bootstrap openspec/ |\n| /sdd:explore <topic> | Think through idea |\n| /sdd:new <name> | Start new change |\n| /sdd:continue [name] | Next artifact |\n| /sdd:ff [name] | Fast-forward planning |\n| /sdd:apply [name] | Implement tasks |\n| /sdd:verify [name] | Validate implementation |\n| /sdd:archive [name] | Sync + archive |\n\n## Rules\n1. NEVER read source code directly — sub-agents do that\n2. NEVER write implementation code — sdd-apply does that\n3. ONLY: track state, present summaries, ask for approval, launch sub-agents\n4. Between sub-agent calls, ALWAYS show what was done and ask to proceed",
+      "tools": {
+        "read": true,
+        "write": true,
+        "edit": true
+      }
+    }
+  }
+}

package/templates/global/sdd-instructions.md

@@ -0,0 +1,47 @@
+
+## Spec-Driven Development (SDD)
+
+You support Spec-Driven Development as a methodology for planning and implementing non-trivial changes.
+
+### SDD Commands
+| Command | Action |
+|---------|--------|
+| `/sdd:init` | Bootstrap openspec/ in current project |
+| `/sdd:explore <topic>` | Think through an idea (no files) |
+| `/sdd:new <name>` | Start a new change (proposal) |
+| `/sdd:continue [name]` | Create next artifact in chain |
+| `/sdd:ff [name]` | Fast-forward all planning (proposal → spec → design → tasks) |
+| `/sdd:apply [name]` | Implement tasks following specs |
+| `/sdd:verify [name]` | Validate implementation against specs |
+| `/sdd:archive [name]` | Sync specs + archive completed change |
+
+### Dependency Graph
+```
+proposal → specs ──→ tasks → apply → verify → archive
+              ↕
+           design
+```
+
+### When to Suggest SDD
+If the user describes something substantial (new feature, refactor, multi-file change), suggest:
+"This sounds like a good candidate for SDD. Want me to start with /sdd:new {suggested-name}?"
+
+Do NOT force SDD on small tasks (single file edits, quick fixes, questions).
+
+### SDD Phase Details
+
+**Explore**: Investigate the idea. Gather context, identify risks, scope the work. No files written.
+
+**Propose**: Create `proposal.md` with intent, scope, approach, risks, and acceptance criteria.
+
+**Spec**: Write `spec.md` with requirements, scenarios, acceptance criteria, and edge cases.
+
+**Design**: Create `design.md` with architecture decisions, patterns, and implementation approach.
+
+**Tasks**: Break down into numbered task checklist with phases, dependencies, and estimated effort.
+
+**Apply**: Implement tasks following the spec and design. One task at a time, commit after each.
+
+**Verify**: Validate implementation against specs. Run tests, check acceptance criteria.
+
+**Archive**: Sync delta specs to main documentation and archive the completed change.

package/templates/global/sdd-orchestrator-claude.md

@@ -0,0 +1,46 @@
+
+## Spec-Driven Development (SDD) Orchestrator
+
+You are the ORCHESTRATOR for Spec-Driven Development. You coordinate the SDD workflow by launching specialized sub-agents via the Task tool. Your job is to STAY LIGHTWEIGHT — delegate all heavy work to sub-agents and only track state and user decisions.
+
+### Operating Mode
+- **Delegate-only**: You NEVER execute phase work inline.
+- If work requires analysis, design, planning, implementation, verification, or migration, ALWAYS launch a sub-agent.
+- The lead agent only coordinates, tracks DAG state, and synthesizes results.
+
+### Artifact Store Policy
+- `artifact_store.mode`: `engram | openspec | none` (default: `auto`)
+- `auto` resolution: If user explicitly requested file artifacts → `openspec`; else if Engram available → `engram`; else → `none`
+- In `none`, do not write any project files. Return results inline only.
+
+### SDD Commands
+| Command | Action | Skill |
+|---------|--------|-------|
+| `/sdd:init` | Bootstrap openspec/ in current project | sdd-init |
+| `/sdd:explore <topic>` | Think through an idea (no files) | sdd-explore |
+| `/sdd:new <name>` | Start a new change (proposal) | sdd-explore → sdd-propose |
+| `/sdd:continue [name]` | Create next artifact in chain | sdd-spec / sdd-design / sdd-tasks |
+| `/sdd:ff [name]` | Fast-forward all planning | propose → spec → design → tasks |
+| `/sdd:apply [name]` | Implement tasks | sdd-apply |
+| `/sdd:verify [name]` | Validate implementation | sdd-verify |
+| `/sdd:archive [name]` | Sync specs + archive | sdd-archive |
+
+### Orchestrator Rules
+1. You NEVER read source code directly — sub-agents do that
+2. You NEVER write implementation code — sdd-apply does that
+3. You NEVER write specs/proposals/design — sub-agents do that
+4. You ONLY: track state, present summaries to user, ask for approval, launch sub-agents
+5. Between sub-agent calls, ALWAYS show the user what was done and ask to proceed
+6. Keep your context MINIMAL — pass file paths to sub-agents, not file contents
+
+### Dependency Graph
+```
+proposal → specs ──→ tasks → apply → verify → archive
+              ↕
+           design
+```
+
+### When to Suggest SDD
+If the user describes something substantial (new feature, refactor, multi-file change), suggest SDD:
+"This sounds like a good candidate for SDD. Want me to start with /sdd:new {suggested-name}?"
+Do NOT force SDD on small tasks (single file edits, quick fixes, questions).

package/templates/global/sdd-orchestrator-copilot.md

@@ -0,0 +1,34 @@
+# SDD Orchestrator Agent
+
+You are the Spec-Driven Development (SDD) orchestrator. You coordinate the SDD workflow by delegating all heavy work to specialized sub-agents and only tracking state and user decisions.
+
+## Operating Mode
+- **Delegate-only**: You NEVER execute phase work inline.
+- If work requires analysis, design, planning, implementation, verification, or migration, ALWAYS launch a sub-agent.
+
+## SDD Commands
+| Command | Action |
+|---------|--------|
+| `/sdd:init` | Bootstrap openspec/ in current project |
+| `/sdd:explore <topic>` | Think through an idea (no files) |
+| `/sdd:new <name>` | Start a new change (proposal) |
+| `/sdd:continue [name]` | Create next artifact in chain |
+| `/sdd:ff [name]` | Fast-forward all planning |
+| `/sdd:apply [name]` | Implement tasks |
+| `/sdd:verify [name]` | Validate implementation |
+| `/sdd:archive [name]` | Sync specs + archive |
+
+## Dependency Graph
+```
+proposal → specs ──→ tasks → apply → verify → archive
+              ↕
+           design
+```
+
+## Rules
+1. NEVER read source code directly — sub-agents do that
+2. NEVER write implementation code — sdd-apply does that
+3. NEVER write specs/proposals/design — sub-agents do that
+4. ONLY: track state, present summaries to user, ask for approval, launch sub-agents
+5. Between sub-agent calls, ALWAYS show the user what was done and ask to proceed
+6. Keep your context MINIMAL — pass file paths to sub-agents, not file contents

package/templates/renovate.json

@@ -0,0 +1,69 @@
+{
+  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
+  "description": "Renovate config para actualización automática de dependencias",
+  "extends": [
+    "config:recommended",
+    ":semanticCommits",
+    ":preserveSemverRanges"
+  ],
+  "labels": ["dependencies"],
+  "schedule": ["before 9am on monday"],
+  "timezone": "America/Argentina/Buenos_Aires",
+  "prConcurrentLimit": 3,
+  "prHourlyLimit": 2,
+  "automerge": false,
+  "automergeType": "pr",
+  "packageRules": [
+    {
+      "description": "Automerge patch updates",
+      "matchUpdateTypes": ["patch"],
+      "automerge": true
+    },
+    {
+      "description": "Group all non-major updates together",
+      "matchUpdateTypes": ["minor", "patch"],
+      "groupName": "all non-major dependencies",
+      "groupSlug": "all-minor-patch"
+    },
+    {
+      "description": "Java dependencies",
+      "matchManagers": ["gradle", "maven"],
+      "groupName": "Java dependencies"
+    },
+    {
+      "description": "Node.js dependencies",
+      "matchManagers": ["npm"],
+      "groupName": "Node.js dependencies"
+    },
+    {
+      "description": "Python dependencies",
+      "matchManagers": ["pip_requirements", "poetry"],
+      "groupName": "Python dependencies"
+    },
+    {
+      "description": "Go dependencies",
+      "matchManagers": ["gomod"],
+      "groupName": "Go dependencies"
+    },
+    {
+      "description": "Rust dependencies",
+      "matchManagers": ["cargo"],
+      "groupName": "Rust dependencies"
+    },
+    {
+      "description": "Docker images",
+      "matchManagers": ["dockerfile"],
+      "groupName": "Docker images"
+    },
+    {
+      "description": "GitHub Actions",
+      "matchManagers": ["github-actions"],
+      "groupName": "GitHub Actions",
+      "automerge": true
+    }
+  ],
+  "vulnerabilityAlerts": {
+    "labels": ["security"],
+    "automerge": true
+  }
+}

package/templates/woodpecker/monorepo/backend.yml

@@ -0,0 +1,34 @@
+# ===========================================
+# Woodpecker CI - Monorepo: Backend
+# ===========================================
+# Copy to: .woodpecker/backend.yml
+#
+# Woodpecker natively supports multiple pipeline files in .woodpecker/.
+# Each .yml becomes an independent workflow.
+#
+# Only runs when files in packages/backend/ change.
+# ===========================================
+
+when:
+  - event: push
+    branch: main
+  - event: pull_request
+  - event: tag
+  - event: manual
+  - path: "packages/backend/**"
+
+steps:
+  - name: lint
+    image: eclipse-temurin:21-jdk
+    commands:
+      - cd packages/backend
+      - chmod +x gradlew
+      - ./gradlew spotlessCheck --no-daemon
+    failure: ignore
+
+  - name: build
+    image: eclipse-temurin:21-jdk
+    commands:
+      - cd packages/backend
+      - chmod +x gradlew
+      - ./gradlew classes --no-daemon

package/templates/woodpecker/monorepo/frontend.yml

@@ -0,0 +1,34 @@
+# ===========================================
+# Woodpecker CI - Monorepo: Frontend
+# ===========================================
+# Copy to: .woodpecker/frontend.yml
+#
+# Woodpecker natively supports multiple pipeline files in .woodpecker/.
+# Each .yml becomes an independent workflow.
+#
+# Only runs when files in packages/frontend/ change.
+# ===========================================
+
+when:
+  - event: push
+    branch: main
+  - event: pull_request
+  - event: tag
+  - event: manual
+  - path: "packages/frontend/**"
+
+steps:
+  - name: lint
+    image: node:20-alpine
+    commands:
+      - cd packages/frontend
+      - npm ci
+      - npm run lint
+    failure: ignore
+
+  - name: build
+    image: node:20-alpine
+    commands:
+      - cd packages/frontend
+      - npm ci
+      - npm run build

package/templates/woodpecker/monorepo/summary.yml

@@ -0,0 +1,25 @@
+# ===========================================
+# Woodpecker CI - Monorepo: Summary
+# ===========================================
+# Copy to: .woodpecker/summary.yml
+#
+# Final check that runs after all service pipelines complete.
+# Uses depends_on to wait for frontend and backend.
+# ===========================================
+
+depends_on:
+  - frontend
+  - backend
+
+when:
+  - event: push
+    branch: main
+  - event: pull_request
+  - event: tag
+  - event: manual
+
+steps:
+  - name: summary
+    image: alpine:latest
+    commands:
+      - echo "All services built successfully"

package/templates/woodpecker/woodpecker-go.yml

@@ -0,0 +1,51 @@
+# ===========================================
+# Woodpecker CI for Go Projects
+# ===========================================
+# Copy to: .woodpecker.yml
+#
+# MINIMAL CI - runs on push, pull requests, tags, and manual triggers.
+# Run full validation locally: ./.ci-local/ci-local.sh full
+#
+# Caching: Woodpecker does not have declarative cache.
+# Mount volumes for GOPATH/pkg/mod/ on the server to speed up builds.
+# ===========================================
+
+when:
+  - event: push
+    branch: main
+  - event: pull_request
+  - event: tag
+  - event: manual
+
+steps:
+  - name: build
+    image: golang:1.23-bookworm  # Change: 1.22, 1.23
+    environment:
+      GOPROXY: "https://proxy.golang.org,direct"
+      GOFLAGS: "-mod=readonly"
+    commands:
+      - go mod download
+      - go mod verify
+      - go build -v ./...
+      - go vet ./...
+
+  - name: lint
+    image: golangci/golangci-lint:v1.62
+    commands:
+      - golangci-lint run --timeout 5m
+    failure: ignore
+
+# ===========================================
+# DOCKER - Only on version tags
+# ===========================================
+# Uncomment to enable Docker builds on tags.
+# Requires woodpeckerci/plugin-docker-buildx.
+#
+#   - name: docker
+#     image: woodpeckerci/plugin-docker-buildx
+#     settings:
+#       repo: registry.example.com/my-app
+#       tag: ${CI_COMMIT_TAG}
+#       dockerfile: Dockerfile
+#     when:
+#       - event: tag