refacil-sdd-ai 4.5.4 → 4.5.7

package/README.md

@@ -153,7 +153,7 @@ All invoked as `/refacil:<name>` in Claude Code, Cursor, or OpenCode.
 | `/refacil:test` | Generate unit tests from the artifacts |
 | `/refacil:verify` | Validate implementation vs specs (with optional autofix) |
 | `/refacil:review` | Quality checklist, emits `.review-passed` if approved |
-| `/refacil:archive` | Archive the completed change + sync specs (requests Jira links) |
+| `/refacil:archive` | Archive the completed change + sync specs (requests task references) |
 | `/refacil:up-code` | Commit + push + PR (runs review if missing) |
 | `/refacil:bug` | Full bugfix flow with regression tests |
 | `/refacil:update` | Detect and apply pending methodology migrations to the current repo |
@@ -259,7 +259,7 @@ From there, the full cycle is:
 - For features/improvements: the CLI moves artifacts to `archive/` and extracts `.review-passed` fields to `review.yaml` inside each affected spec.
 - For bugs: manual archiving, creates `refacil-sdd/specs/fix-*/spec.md` in standard format + `review.yaml`.
 - A single branch can accumulate multiple bugs, each in its own independent `fix-*/` folder.
-- `/refacil:archive` always requests one or more **Jira links** associated with the change before proceeding. Links are stored in `review.yaml` under the `jiraTasks` field (YAML list). This field is mandatory — archiving does not proceed until the user provides at least one link.
+- `/refacil:archive` always requests one or more **task references** associated with the change before proceeding. Accepted formats: URL, ticket/issue identifier, or task name. References are stored in `review.yaml` under the `taskReferences` field (YAML list). This field is mandatory — archiving does not proceed until the user provides at least one reference.
 
 ---
 

package/lib/installer.js

@@ -141,7 +141,9 @@ function transformFrontmatterForCursor(content) {
     }
     if (line.startsWith('model:')) {
       const value = line.slice('model:'.length).trim();
-      if (value === 'sonnet' || value === 'opus' || value === 'haiku') {
+      // Claude Code short aliases (and plan-mode alias) → Cursor always inherits session model
+      const ccAlias = value.toLowerCase();
+      if (ccAlias === 'sonnet' || ccAlias === 'opus' || ccAlias === 'haiku' || ccAlias === 'opusplan') {
         out.push('model: inherit');
       } else {
         out.push(line);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "refacil-sdd-ai",
-  "version": "4.5.4",
+  "version": "4.5.7",
   "description": "SDD-AI: Specification-Driven Development with AI — development methodology using AI with Claude Code, Cursor and OpenCode",
   "bin": {
     "refacil-sdd-ai": "./bin/cli.js"

package/skills/archive/SKILL.md

@@ -34,23 +34,33 @@ Verify the change is truly complete:
 If any of checks 1-3 fail, inform the user but allow them to decide whether to continue.
 If check 4 fails, archiving cannot continue.
 
-### Step 1.5: Request Jira links (traceability — mandatory)
+### Step 1.5: Request task reference(s) (traceability — mandatory)
 
-Before proceeding to archiving, ask the user for the Jira links associated with the change:
+Before proceeding to archiving, ask the user for the task reference(s) associated with the change (URL, issue/ticket number, or short task name):
 
 ```
-Jira link(s) associated with this change (if multiple, separate with commas):
+Task reference(s) associated with this change (URL, ticket number, or task name; if multiple, separate with commas):
 ```
 
 **Rules:**
-- The user may enter one or multiple links separated by commas in a single message.
-- If the user provides no link (answers empty, "n", "no", "none", blank Enter), **block the archiving** and ask again:
+- The user may enter one or multiple references separated by commas in a single message.
+- Accepted formats: URL (`https://tracker.company.com/TASK-123`), identifier (`TASK-123`, `INC-9001`), or short descriptive name (`ajuste checkout`).
+- Minimum validation rule for each reference (operational and mandatory):
+  - `URL`: starts with `http://` or `https://` and has at least one non-space character after the protocol.
+  - `identifier`: matches `^[A-Za-z][A-Za-z0-9_-]*-\d+$` (examples: `BP-4610`, `INC-9001`).
+  - `short name`: 3-80 characters, includes at least one letter, and is not only symbols/spaces.
+- If the user provides no reference (answers empty, "n", "no", "none", blank Enter), **block the archiving** and ask again:
   ```
-  Cannot archive without at least one Jira link.
-  Provide the link to the task that originated this change to continue.
+  Cannot archive without at least one task reference.
+  Provide the task URL, identifier, or name that originated this change to continue.
   ```
-- Repeat until at least one valid URL is received.
-- Save the links in `jiraTasks` to use when writing `review.yaml` in the following steps.
+- If the user provides a non-empty but invalid value (for example: `---`, `???`, `123`, `_`), **reject it** and ask again:
+  ```
+  Invalid task reference format.
+  Use one of: URL (https://...), identifier (ABC-123), or short task name (3-80 chars, includes letters).
+  ```
+- Repeat until at least one valid reference is received.
+- Save the references in `taskReferences` to use when writing `review.yaml` in the following steps.
 
 ### Step 2: Determine change type
 
@@ -75,7 +85,7 @@ Bug fixes only contain `summary.md` (and optionally `.review-passed`). The CLI `
 
 2. **Document in specs**: using the content read in step 0, create an individual spec at `$(git rev-parse --show-toplevel)/refacil-sdd/specs/[descriptive-name]/spec.md`.
 
-   **Spec folder name**: Use a short, clear kebab-case description of the bug (e.g. `fix-session-timeout-redis`, `fix-null-pointer-payment-callback`). **Do NOT use ticket IDs** (REF-123, JIRA-456, etc.) — the name must be descriptive so `/refacil:explore` can find and understand the fix without external context.
+   **Spec folder name**: Use a short, clear kebab-case description of the bug (e.g. `fix-session-timeout-redis`, `fix-null-pointer-payment-callback`). **Do NOT use ticket IDs** (REF-123, TASK-456, etc.) — the name must be descriptive so `/refacil:explore` can find and understand the fix without external context.
 
    Content of `spec.md` (Refacil SDD spec layout):
    ```markdown
@@ -97,7 +107,7 @@ Bug fixes only contain `summary.md` (and optionally `.review-passed`). The CLI `
    - **THEN** the system SHALL [normal behavior without regression]
    ```
 
-3. **Persist review metadata separately**: create `$(git rev-parse --show-toplevel)/refacil-sdd/specs/[descriptive-name]/review.yaml` with the fields from `.review-passed` plus the Jira links from Step 1.5:
+3. **Persist review metadata separately**: create `$(git rev-parse --show-toplevel)/refacil-sdd/specs/[descriptive-name]/review.yaml` with the fields from `.review-passed` plus the task references from Step 1.5:
    ```yaml
    verdict: APROBADO|APROBADO CON OBSERVACIONES
    date: 2026-04-10T00:00:00.000Z
@@ -105,8 +115,9 @@ Bug fixes only contain `summary.md` (and optionally `.review-passed`). The CLI `
    summary: "..."
    failCount: 0
    blockers: false
-   jiraTasks:
-     - https://your-company.atlassian.net/browse/REF-123
+   taskReferences:
+     - https://tracker.company.com/TASK-123
+     - TASK-123
    ```
 
 4. Continue to **Step 3**.
@@ -123,7 +134,7 @@ The spec and review evidence are written **before** running the CLI archive comm
 
 2. **Persist review evidence (before archiving)**:
    - Read `refacil-sdd/changes/<changeName>/.review-passed` (dotfile — use `ls -la` or read by explicit path, not directory listing).
-   - Create/update `refacil-sdd/specs/<specName>/review.yaml` with its fields plus `jiraTasks` from Step 1.5:
+   - Create/update `refacil-sdd/specs/<specName>/review.yaml` with its fields plus `taskReferences` from Step 1.5:
      ```yaml
      verdict: APROBADO|APROBADO CON OBSERVACIONES
      date: 2026-04-10T00:00:00.000Z
@@ -131,8 +142,9 @@ The spec and review evidence are written **before** running the CLI archive comm
      summary: "..."
      failCount: 0
      blockers: false
-     jiraTasks:
-       - https://your-company.atlassian.net/browse/REF-123
+     taskReferences:
+       - https://tracker.company.com/TASK-123
+       - TASK-123
      ```
    - If `review.yaml` already exists, update only the fields that changed without removing others.
 

package/skills/prereqs/METHODOLOGY-CONTRACT.md

@@ -127,6 +127,8 @@ If the user does not request detail, use concise mode.
 
 - `archive` requires `.review-passed` as a blocking precondition (verify existence according to **§8**).
 - When archiving regular changes (proposal-driven flow), the `.review-passed` metadata must be persisted in `refacil-sdd/specs/`.
+- `archive` must request and persist at least one task reference for traceability. Accepted formats: URL, ticket/issue identifier, or short task name.
+- The recommended field in `review.yaml` is `taskReferences` (YAML list). Do not enforce provider-specific fields such as `jiraTasks`.
 - The recommended format is `review.yaml` inside each affected spec folder.
 - If it cannot be reliably mapped to specific specs, record the evidence in `refacil-sdd/specs/review-metadata.yaml`.
 

package/skills/up-code/SKILL.md

@@ -83,15 +83,17 @@ Run `git push -u origin [current-branch]` to push the changes.
    Which branch do you want to create the PR to? (recommended: testing)
    ```
 
-   If the user indicates a different branch than `testing`, verify it exists on the remote with `git branch -r | grep <indicated-branch>` before generating the link. If it does not exist, inform the user and ask them to confirm or correct the name.
+  If the user indicates a different branch than `testing`, verify it exists on the remote by inspecting `git branch -r` output before generating the link. If it does not exist, inform the user and ask them to confirm or correct the name.
 
-3. Get the remote repository URL with `git remote get-url origin` and determine the hosting to generate the correct link:
+3. Get the remote repository URL with `git remote get-url origin` and detect the VCS hosting used by this repository to generate the correct PR/MR link:
    - **GitHub** (url contains `github.com`): `https://github.com/[owner]/[repo]/compare/[target-branch]...[current-branch]?expand=1`
-   - **Bitbucket** (url contains `bitbucket.org`): `https://bitbucket.org/[workspace]/[repo]/pull-requests/new?source=[current-branch]&dest=[target-branch]`
-   - If hosting cannot be determined, show both formats for the user to choose.
-   - Note: for SSH URLs (`git@github.com:owner/repo.git` or `git@bitbucket.org:workspace/repo.git`), extract owner/workspace and repo from the path after `:`.
+   - **Bitbucket Cloud** (url contains `bitbucket.org`): `https://bitbucket.org/[workspace]/[repo]/pull-requests/new?source=[current-branch]&dest=[target-branch]`
+   - **GitLab** (url contains `gitlab.` or `gitlab.com`): `https://[gitlab-host]/[group]/[repo]/-/merge_requests/new?merge_request[source_branch]=[current-branch]&merge_request[target_branch]=[target-branch]`
+   - **Azure DevOps** (url contains `dev.azure.com` or `visualstudio.com`): build the "create PR" URL for the detected project/repo using source and target branches.
+   - For SSH remotes (`git@host:group/repo.git`), extract host/namespace/repo from the segment after `:`.
+   - If hosting cannot be determined, do not assume a provider: show the detected remote URL and ask the user which platform is used before generating the final PR/MR link.
 
-4. Show the link to the user and recommend PR to `testing`:
+4. Show the generated link (provider-specific) to the user and recommend PR to `testing`:
 ```
  Create your PR here: [link]