@massa-ai/opencode-plugin 1.31.0 → 1.33.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
@@ -35,12 +35,13 @@ The `lens` field in the capability packet selects the audit behavior:
35
35
  | `requirements` | Requirements, spec, acceptance, scope alignment | `workflows/requirements/requirements-audit.md` |
36
36
  | `code-quality` | SOLID, Clean Code, KISS, YAGNI, DRY, maintainability | `workflows/code-quality/code-quality-audit.md` |
37
37
  | `performance` | Performance hotspots, allocation, latency, throughput | Domain-specific; no fixed reference |
38
+ | `tests` | Coverage, regression protection, assertion quality, variation | `workflows/tests/tests-audit.md` |
38
39
 
39
40
  All lenses share `references/audit-scope.md` (scope rules) and `references/audit-report-io.md` (report format).
40
41
 
41
42
  ## Inputs
42
43
  - `scope`: the target area, diff, or module to audit.
43
- - `lens`: one of `bugs | architecture | security | requirements | code-quality | performance` (required).
44
+ - `lens`: one of `bugs | architecture | security | requirements | code-quality | performance | tests` (required).
44
45
  - `inputs`: recalled facts, existing audit reports, source pointers.
45
46
  - `sensors`: static checks available for the lens (lint, typecheck, security scanners).
46
47
 
@@ -9,12 +9,13 @@ permission: { edit: allow, bash: allow }
9
9
  # Test Engineer Agent Skill
10
10
 
11
11
  ## Mission
12
- Generate a testing strategy that covers unit, integration, edge cases, negative scenarios, and acceptance criteria.
12
+ Generate a testing strategy that covers unit, integration, edge cases, negative scenarios, and acceptance criteria, and that catches the five distinct error classes a test suite must cover: business-logic errors, code no test touched, hardcoded-example brittleness, built-the-wrong-thing, and drift over time.
13
13
 
14
14
  ## Responsibilities
15
15
  - Define unit test cases for core logic.
16
16
  - Define integration test cases for boundaries.
17
17
  - Identify edge cases and negative scenarios.
18
+ - Design variation/property-style test cases — vary inputs beyond the fixture example (bounds, parameter changes) — technique-level, library-neutral.
18
19
  - Produce a test plan aligned with acceptance criteria.
19
20
  - Ensure acceptance coverage maps to spec criteria.
20
21
 
@@ -35,12 +35,13 @@ The `lens` field in the capability packet selects the audit behavior:
35
35
  | `requirements` | Requirements, spec, acceptance, scope alignment | `workflows/requirements/requirements-audit.md` |
36
36
  | `code-quality` | SOLID, Clean Code, KISS, YAGNI, DRY, maintainability | `workflows/code-quality/code-quality-audit.md` |
37
37
  | `performance` | Performance hotspots, allocation, latency, throughput | Domain-specific; no fixed reference |
38
+ | `tests` | Coverage, regression protection, assertion quality, variation | `workflows/tests/tests-audit.md` |
38
39
 
39
40
  All lenses share `references/audit-scope.md` (scope rules) and `references/audit-report-io.md` (report format).
40
41
 
41
42
  ## Inputs
42
43
  - `scope`: the target area, diff, or module to audit.
43
- - `lens`: one of `bugs | architecture | security | requirements | code-quality | performance` (required).
44
+ - `lens`: one of `bugs | architecture | security | requirements | code-quality | performance | tests` (required).
44
45
  - `inputs`: recalled facts, existing audit reports, source pointers.
45
46
  - `sensors`: static checks available for the lens (lint, typecheck, security scanners).
46
47
 
@@ -9,12 +9,13 @@ permission: { edit: allow, bash: allow }
9
9
  # Test Engineer Agent Skill
10
10
 
11
11
  ## Mission
12
- Generate a testing strategy that covers unit, integration, edge cases, negative scenarios, and acceptance criteria.
12
+ Generate a testing strategy that covers unit, integration, edge cases, negative scenarios, and acceptance criteria, and that catches the five distinct error classes a test suite must cover: business-logic errors, code no test touched, hardcoded-example brittleness, built-the-wrong-thing, and drift over time.
13
13
 
14
14
  ## Responsibilities
15
15
  - Define unit test cases for core logic.
16
16
  - Define integration test cases for boundaries.
17
17
  - Identify edge cases and negative scenarios.
18
+ - Design variation/property-style test cases — vary inputs beyond the fixture example (bounds, parameter changes) — technique-level, library-neutral.
18
19
  - Produce a test plan aligned with acceptance criteria.
19
20
  - Ensure acceptance coverage maps to spec criteria.
20
21
 
@@ -35,12 +35,13 @@ The `lens` field in the capability packet selects the audit behavior:
35
35
  | `requirements` | Requirements, spec, acceptance, scope alignment | `workflows/requirements/requirements-audit.md` |
36
36
  | `code-quality` | SOLID, Clean Code, KISS, YAGNI, DRY, maintainability | `workflows/code-quality/code-quality-audit.md` |
37
37
  | `performance` | Performance hotspots, allocation, latency, throughput | Domain-specific; no fixed reference |
38
+ | `tests` | Coverage, regression protection, assertion quality, variation | `workflows/tests/tests-audit.md` |
38
39
 
39
40
  All lenses share `references/audit-scope.md` (scope rules) and `references/audit-report-io.md` (report format).
40
41
 
41
42
  ## Inputs
42
43
  - `scope`: the target area, diff, or module to audit.
43
- - `lens`: one of `bugs | architecture | security | requirements | code-quality | performance` (required).
44
+ - `lens`: one of `bugs | architecture | security | requirements | code-quality | performance | tests` (required).
44
45
  - `inputs`: recalled facts, existing audit reports, source pointers.
45
46
  - `sensors`: static checks available for the lens (lint, typecheck, security scanners).
46
47
 
@@ -9,12 +9,13 @@ permission: { edit: allow, bash: allow }
9
9
  # Test Engineer Agent Skill
10
10
 
11
11
  ## Mission
12
- Generate a testing strategy that covers unit, integration, edge cases, negative scenarios, and acceptance criteria.
12
+ Generate a testing strategy that covers unit, integration, edge cases, negative scenarios, and acceptance criteria, and that catches the five distinct error classes a test suite must cover: business-logic errors, code no test touched, hardcoded-example brittleness, built-the-wrong-thing, and drift over time.
13
13
 
14
14
  ## Responsibilities
15
15
  - Define unit test cases for core logic.
16
16
  - Define integration test cases for boundaries.
17
17
  - Identify edge cases and negative scenarios.
18
+ - Design variation/property-style test cases — vary inputs beyond the fixture example (bounds, parameter changes) — technique-level, library-neutral.
18
19
  - Produce a test plan aligned with acceptance criteria.
19
20
  - Ensure acceptance coverage maps to spec criteria.
20
21
 
@@ -35,12 +35,13 @@ The `lens` field in the capability packet selects the audit behavior:
35
35
  | `requirements` | Requirements, spec, acceptance, scope alignment | `workflows/requirements/requirements-audit.md` |
36
36
  | `code-quality` | SOLID, Clean Code, KISS, YAGNI, DRY, maintainability | `workflows/code-quality/code-quality-audit.md` |
37
37
  | `performance` | Performance hotspots, allocation, latency, throughput | Domain-specific; no fixed reference |
38
+ | `tests` | Coverage, regression protection, assertion quality, variation | `workflows/tests/tests-audit.md` |
38
39
 
39
40
  All lenses share `references/audit-scope.md` (scope rules) and `references/audit-report-io.md` (report format).
40
41
 
41
42
  ## Inputs
42
43
  - `scope`: the target area, diff, or module to audit.
43
- - `lens`: one of `bugs | architecture | security | requirements | code-quality | performance` (required).
44
+ - `lens`: one of `bugs | architecture | security | requirements | code-quality | performance | tests` (required).
44
45
  - `inputs`: recalled facts, existing audit reports, source pointers.
45
46
  - `sensors`: static checks available for the lens (lint, typecheck, security scanners).
46
47
 
@@ -9,12 +9,13 @@ permission: { edit: allow, bash: allow }
9
9
  # Test Engineer Agent Skill
10
10
 
11
11
  ## Mission
12
- Generate a testing strategy that covers unit, integration, edge cases, negative scenarios, and acceptance criteria.
12
+ Generate a testing strategy that covers unit, integration, edge cases, negative scenarios, and acceptance criteria, and that catches the five distinct error classes a test suite must cover: business-logic errors, code no test touched, hardcoded-example brittleness, built-the-wrong-thing, and drift over time.
13
13
 
14
14
  ## Responsibilities
15
15
  - Define unit test cases for core logic.
16
16
  - Define integration test cases for boundaries.
17
17
  - Identify edge cases and negative scenarios.
18
+ - Design variation/property-style test cases — vary inputs beyond the fixture example (bounds, parameter changes) — technique-level, library-neutral.
18
19
  - Produce a test plan aligned with acceptance criteria.
19
20
  - Ensure acceptance coverage maps to spec criteria.
20
21
 
@@ -35,12 +35,13 @@ The `lens` field in the capability packet selects the audit behavior:
35
35
  | `requirements` | Requirements, spec, acceptance, scope alignment | `workflows/requirements/requirements-audit.md` |
36
36
  | `code-quality` | SOLID, Clean Code, KISS, YAGNI, DRY, maintainability | `workflows/code-quality/code-quality-audit.md` |
37
37
  | `performance` | Performance hotspots, allocation, latency, throughput | Domain-specific; no fixed reference |
38
+ | `tests` | Coverage, regression protection, assertion quality, variation | `workflows/tests/tests-audit.md` |
38
39
 
39
40
  All lenses share `references/audit-scope.md` (scope rules) and `references/audit-report-io.md` (report format).
40
41
 
41
42
  ## Inputs
42
43
  - `scope`: the target area, diff, or module to audit.
43
- - `lens`: one of `bugs | architecture | security | requirements | code-quality | performance` (required).
44
+ - `lens`: one of `bugs | architecture | security | requirements | code-quality | performance | tests` (required).
44
45
  - `inputs`: recalled facts, existing audit reports, source pointers.
45
46
  - `sensors`: static checks available for the lens (lint, typecheck, security scanners).
46
47
 
@@ -9,12 +9,13 @@ permission: { edit: allow, bash: allow }
9
9
  # Test Engineer Agent Skill
10
10
 
11
11
  ## Mission
12
- Generate a testing strategy that covers unit, integration, edge cases, negative scenarios, and acceptance criteria.
12
+ Generate a testing strategy that covers unit, integration, edge cases, negative scenarios, and acceptance criteria, and that catches the five distinct error classes a test suite must cover: business-logic errors, code no test touched, hardcoded-example brittleness, built-the-wrong-thing, and drift over time.
13
13
 
14
14
  ## Responsibilities
15
15
  - Define unit test cases for core logic.
16
16
  - Define integration test cases for boundaries.
17
17
  - Identify edge cases and negative scenarios.
18
+ - Design variation/property-style test cases — vary inputs beyond the fixture example (bounds, parameter changes) — technique-level, library-neutral.
18
19
  - Produce a test plan aligned with acceptance criteria.
19
20
  - Ensure acceptance coverage maps to spec criteria.
20
21
 
@@ -35,12 +35,13 @@ The `lens` field in the capability packet selects the audit behavior:
35
35
  | `requirements` | Requirements, spec, acceptance, scope alignment | `workflows/requirements/requirements-audit.md` |
36
36
  | `code-quality` | SOLID, Clean Code, KISS, YAGNI, DRY, maintainability | `workflows/code-quality/code-quality-audit.md` |
37
37
  | `performance` | Performance hotspots, allocation, latency, throughput | Domain-specific; no fixed reference |
38
+ | `tests` | Coverage, regression protection, assertion quality, variation | `workflows/tests/tests-audit.md` |
38
39
 
39
40
  All lenses share `references/audit-scope.md` (scope rules) and `references/audit-report-io.md` (report format).
40
41
 
41
42
  ## Inputs
42
43
  - `scope`: the target area, diff, or module to audit.
43
- - `lens`: one of `bugs | architecture | security | requirements | code-quality | performance` (required).
44
+ - `lens`: one of `bugs | architecture | security | requirements | code-quality | performance | tests` (required).
44
45
  - `inputs`: recalled facts, existing audit reports, source pointers.
45
46
  - `sensors`: static checks available for the lens (lint, typecheck, security scanners).
46
47
 
@@ -9,12 +9,13 @@ permission: { edit: allow, bash: allow }
9
9
  # Test Engineer Agent Skill
10
10
 
11
11
  ## Mission
12
- Generate a testing strategy that covers unit, integration, edge cases, negative scenarios, and acceptance criteria.
12
+ Generate a testing strategy that covers unit, integration, edge cases, negative scenarios, and acceptance criteria, and that catches the five distinct error classes a test suite must cover: business-logic errors, code no test touched, hardcoded-example brittleness, built-the-wrong-thing, and drift over time.
13
13
 
14
14
  ## Responsibilities
15
15
  - Define unit test cases for core logic.
16
16
  - Define integration test cases for boundaries.
17
17
  - Identify edge cases and negative scenarios.
18
+ - Design variation/property-style test cases — vary inputs beyond the fixture example (bounds, parameter changes) — technique-level, library-neutral.
18
19
  - Produce a test plan aligned with acceptance criteria.
19
20
  - Ensure acceptance coverage maps to spec criteria.
20
21
 
@@ -35,12 +35,13 @@ The `lens` field in the capability packet selects the audit behavior:
35
35
  | `requirements` | Requirements, spec, acceptance, scope alignment | `workflows/requirements/requirements-audit.md` |
36
36
  | `code-quality` | SOLID, Clean Code, KISS, YAGNI, DRY, maintainability | `workflows/code-quality/code-quality-audit.md` |
37
37
  | `performance` | Performance hotspots, allocation, latency, throughput | Domain-specific; no fixed reference |
38
+ | `tests` | Coverage, regression protection, assertion quality, variation | `workflows/tests/tests-audit.md` |
38
39
 
39
40
  All lenses share `references/audit-scope.md` (scope rules) and `references/audit-report-io.md` (report format).
40
41
 
41
42
  ## Inputs
42
43
  - `scope`: the target area, diff, or module to audit.
43
- - `lens`: one of `bugs | architecture | security | requirements | code-quality | performance` (required).
44
+ - `lens`: one of `bugs | architecture | security | requirements | code-quality | performance | tests` (required).
44
45
  - `inputs`: recalled facts, existing audit reports, source pointers.
45
46
  - `sensors`: static checks available for the lens (lint, typecheck, security scanners).
46
47
 
@@ -9,12 +9,13 @@ permission: { edit: allow, bash: allow }
9
9
  # Test Engineer Agent Skill
10
10
 
11
11
  ## Mission
12
- Generate a testing strategy that covers unit, integration, edge cases, negative scenarios, and acceptance criteria.
12
+ Generate a testing strategy that covers unit, integration, edge cases, negative scenarios, and acceptance criteria, and that catches the five distinct error classes a test suite must cover: business-logic errors, code no test touched, hardcoded-example brittleness, built-the-wrong-thing, and drift over time.
13
13
 
14
14
  ## Responsibilities
15
15
  - Define unit test cases for core logic.
16
16
  - Define integration test cases for boundaries.
17
17
  - Identify edge cases and negative scenarios.
18
+ - Design variation/property-style test cases — vary inputs beyond the fixture example (bounds, parameter changes) — technique-level, library-neutral.
18
19
  - Produce a test plan aligned with acceptance criteria.
19
20
  - Ensure acceptance coverage maps to spec criteria.
20
21
 
@@ -35,12 +35,13 @@ The `lens` field in the capability packet selects the audit behavior:
35
35
  | `requirements` | Requirements, spec, acceptance, scope alignment | `workflows/requirements/requirements-audit.md` |
36
36
  | `code-quality` | SOLID, Clean Code, KISS, YAGNI, DRY, maintainability | `workflows/code-quality/code-quality-audit.md` |
37
37
  | `performance` | Performance hotspots, allocation, latency, throughput | Domain-specific; no fixed reference |
38
+ | `tests` | Coverage, regression protection, assertion quality, variation | `workflows/tests/tests-audit.md` |
38
39
 
39
40
  All lenses share `references/audit-scope.md` (scope rules) and `references/audit-report-io.md` (report format).
40
41
 
41
42
  ## Inputs
42
43
  - `scope`: the target area, diff, or module to audit.
43
- - `lens`: one of `bugs | architecture | security | requirements | code-quality | performance` (required).
44
+ - `lens`: one of `bugs | architecture | security | requirements | code-quality | performance | tests` (required).
44
45
  - `inputs`: recalled facts, existing audit reports, source pointers.
45
46
  - `sensors`: static checks available for the lens (lint, typecheck, security scanners).
46
47
 
@@ -9,12 +9,13 @@ permission: { edit: allow, bash: allow }
9
9
  # Test Engineer Agent Skill
10
10
 
11
11
  ## Mission
12
- Generate a testing strategy that covers unit, integration, edge cases, negative scenarios, and acceptance criteria.
12
+ Generate a testing strategy that covers unit, integration, edge cases, negative scenarios, and acceptance criteria, and that catches the five distinct error classes a test suite must cover: business-logic errors, code no test touched, hardcoded-example brittleness, built-the-wrong-thing, and drift over time.
13
13
 
14
14
  ## Responsibilities
15
15
  - Define unit test cases for core logic.
16
16
  - Define integration test cases for boundaries.
17
17
  - Identify edge cases and negative scenarios.
18
+ - Design variation/property-style test cases — vary inputs beyond the fixture example (bounds, parameter changes) — technique-level, library-neutral.
18
19
  - Produce a test plan aligned with acceptance criteria.
19
20
  - Ensure acceptance coverage maps to spec criteria.
20
21
 
@@ -410,9 +410,9 @@ var init_massa_ai_config = __esm(() => {
410
410
  },
411
411
  embedding: {
412
412
  provider: "ollama",
413
- model: "nomic-embed-text:latest",
413
+ model: "qwen3-embedding:4b",
414
414
  baseURL: "http://localhost:11434",
415
- dimensions: 768
415
+ dimensions: 2560
416
416
  },
417
417
  compression: {
418
418
  defaultStrategy: "code_structure",
package/dist/index.js CHANGED
@@ -409,9 +409,9 @@ var init_massa_ai_config = __esm(() => {
409
409
  },
410
410
  embedding: {
411
411
  provider: "ollama",
412
- model: "nomic-embed-text:latest",
412
+ model: "qwen3-embedding:4b",
413
413
  baseURL: "http://localhost:11434",
414
- dimensions: 768
414
+ dimensions: 2560
415
415
  },
416
416
  compression: {
417
417
  defaultStrategy: "code_structure",
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@massa-ai/opencode-plugin",
3
- "version": "1.31.0",
3
+ "version": "1.33.0",
4
4
  "description": "massa-ai plugin for OpenCode - Semantic code search, memory, and context compression",
5
5
  "type": "module",
6
6
  "main": "dist/index.js",
@@ -23,8 +23,8 @@
23
23
  "dependencies": {
24
24
  "@opencode-ai/plugin": "^1.2.15",
25
25
  "@opencode-ai/sdk": "^1.2.15",
26
- "@massa-ai/core": "^1.31.0",
27
- "@massa-ai/shared": "^1.31.0"
26
+ "@massa-ai/core": "^1.33.0",
27
+ "@massa-ai/shared": "^1.33.0"
28
28
  },
29
29
  "devDependencies": {
30
30
  "@types/node": "^22.10.5",