@xn-intenton-z2a/agentic-lib 7.1.68 → 7.1.69

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.
@@ -721,15 +721,35 @@ jobs:
721
721
  run: |
722
722
  npm run build:web 2>/dev/null || echo "No build:web script"
723
723
 
724
+ - name: Run tests before committing
725
+ id: pre-commit-test
726
+ if: steps.issue.outputs.issue-number != ''
727
+ run: |
728
+ CONFIG="${{ needs.params.outputs.config-path }}"
729
+ TEST_CMD=$(grep -E '^\s*test\s*=' "$CONFIG" 2>/dev/null | sed 's/.*=\s*"\(.*\)"/\1/' | head -1)
730
+ TEST_CMD="${TEST_CMD:-npm ci && npm test}"
731
+ echo "Running: $TEST_CMD"
732
+ set +e
733
+ eval "$TEST_CMD" 2>&1 | tail -30
734
+ EXIT_CODE=$?
735
+ set -e
736
+ if [ $EXIT_CODE -ne 0 ]; then
737
+ echo "tests-passed=false" >> $GITHUB_OUTPUT
738
+ echo "WARNING: Tests failed (exit $EXIT_CODE) — skipping commit and PR"
739
+ else
740
+ echo "tests-passed=true" >> $GITHUB_OUTPUT
741
+ echo "Tests passed"
742
+ fi
743
+
724
744
  - name: Commit and push
725
- if: github.repository != 'xn-intenton-z2a/agentic-lib' && steps.issue.outputs.issue-number != '' && needs.params.outputs.dry-run != 'true'
745
+ if: github.repository != 'xn-intenton-z2a/agentic-lib' && steps.issue.outputs.issue-number != '' && needs.params.outputs.dry-run != 'true' && steps.pre-commit-test.outputs.tests-passed == 'true'
726
746
  uses: ./.github/agentic-lib/actions/commit-if-changed
727
747
  with:
728
748
  commit-message: "agentic-step: transform issue #${{ steps.issue.outputs.issue-number }}"
729
749
  push-ref: ${{ steps.branch.outputs.branchName }}
730
750
 
731
751
  - name: Create PR and attempt merge
732
- if: github.repository != 'xn-intenton-z2a/agentic-lib' && steps.issue.outputs.issue-number != '' && needs.params.outputs.dry-run != 'true'
752
+ if: github.repository != 'xn-intenton-z2a/agentic-lib' && steps.issue.outputs.issue-number != '' && needs.params.outputs.dry-run != 'true' && steps.pre-commit-test.outputs.tests-passed == 'true'
733
753
  uses: actions/github-script@v8
734
754
  with:
735
755
  script: |
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@xn-intenton-z2a/agentic-lib",
3
- "version": "7.1.68",
3
+ "version": "7.1.69",
4
4
  "description": "Agentic-lib Agentic Coding Systems SDK powering automated GitHub workflows.",
5
5
  "type": "module",
6
6
  "scripts": {
@@ -1,17 +1,17 @@
1
1
  You are providing the entire new content of source files, test files, documentation files,
2
2
  and other necessary files with all necessary changes applied to resolve a possible build or test
3
- problem. Focus on high-impact, functional fixes that address core issues rather than superficial
4
- changes or excessive debugging or validation. If the problem is in an area of the code with little
5
- value you may re-implement it or remove it.
3
+ problem. Fix the root cause. If the problem is in an area of the code with little
4
+ relevance to the mission you may re-implement it or remove it.
6
5
 
7
- Apply the contributing guidelines to your response, and when suggesting enhancements, consider the tone
8
- and direction of the contributing guidelines. Prioritize changes that deliver substantial user value
9
- and maintain the integrity of the codebase's primary purpose.
6
+ Apply the contributing guidelines to your response.
10
7
 
11
8
  You may complete the implementation of a feature and/or bring the code output in line with the README
12
9
  or other documentation. Do as much as you can all at once so that the build runs (even with nothing
13
10
  to build) and the tests pass and the main at least doesn't output an error.
14
11
 
12
+ Your goal is mission complete — if the mission can be fully accomplished while fixing this issue,
13
+ do it. Don't limit yourself to the minimal fix when you can deliver the whole mission in one pass.
14
+
15
15
  The repository has a website in `src/web/` that uses the JS library. If a fix affects library
16
16
  exports or behaviour, also update the website files to stay in sync.
17
17
 
@@ -1,14 +1,25 @@
1
1
  You are providing the entire new content of source files, test files, documentation files, and other necessary
2
- files with all necessary changes applied to deliver the resolution to an issue. Focus on high-impact,
3
- functional solutions that address core issues rather than superficial changes or excessive code polishing.
4
- Implement as much as you can and refer to the projects features and mission statement when expanding the code
2
+ files with all necessary changes applied to deliver the resolution to an issue.
3
+ Implement as much as you can and refer to the project's features and mission statement when expanding the code
5
4
  beyond the scope of the original issue. Implement whole features and do not leave stubbed out or pretended code.
6
5
 
7
- Apply the contributing guidelines to your response, and when suggesting enhancements, consider the tone and direction
8
- of the contributing guidelines. Prioritize changes that deliver user value and maintain the integrity
9
- of the codebase's primary purpose.
6
+ Apply the contributing guidelines to your response.
10
7
 
11
- Do as much as you can all at once.
8
+ Do as much as you can all at once. Your goal is mission complete — if the mission can be fully
9
+ accomplished in this single transform, it should be. Deliver all acceptance criteria, tests, website,
10
+ docs, and README in one pass. Only leave work for a follow-up if it genuinely cannot fit.
11
+
12
+ ## Tests Must Pass
13
+
14
+ Your changes MUST leave all existing tests passing. If you change function signatures, return values, or
15
+ output formats, you MUST also update the corresponding tests. The mission's acceptance criteria are the
16
+ source of truth for expected values — if tests and acceptance criteria disagree, fix the tests to match
17
+ the acceptance criteria and fix the code to pass those tests.
18
+
19
+ When writing both tests and implementation:
20
+ - Write tests that match the acceptance criteria in MISSION.md exactly (casing, types, error classes)
21
+ - Ensure the implementation passes those tests before delivering
22
+ - Do not write tests with different expectations than the implementation produces
12
23
 
13
24
  Follow the linting guidelines and the formatting guidelines from the included config.
14
25
 
@@ -1,5 +1,5 @@
1
1
  Please generate the name and specification for a software feature which will be added or updated to action the supplied feature prompt.
2
- Prioritize features that deliver substantial user impact and core functionality that solves real problems. Focus on capabilities that directly enhance the product's primary purpose rather than cosmetic improvements, excessive validation, or polishing. Aim for achievable, high-impact outcomes within a single repository, not a grandiose vision or bloated feature set.
2
+ Features must advance the mission stated in MISSION.md. Aim for achievable outcomes within a single repository, not a grandiose vision or bloated feature set.
3
3
 
4
4
  You may only create features to only change the source file, test file, README file, dependencies file, and examples directory content. You may not create features that request new files, delete existing files, or change the other files provided in the prompt context.
5
5
  If there are more than the maximum number of features in the repository, you may delete a feature but preferably, you should identify an existing feature that is most similar or related to the new feature and modify it to incorporate aspects of the new feature.
@@ -12,7 +12,7 @@ Don't use any quote escape sequences in the feature text.
12
12
  Generally, the whole document might need to be extracted and stored as JSON so be careful to avoid any JSON escape
13
13
  sequences in any part of the document. Use spacing to make it readable and avoid complex Markdown formatting.
14
14
 
15
- The feature will be iterated upon to incrementally deliver measurable value to users. Each iteration should focus on core functionality that addresses user needs rather than superficial enhancements. New features should be thematically distinct from other features.
15
+ The feature will be iterated upon to incrementally advance the mission. New features should be thematically distinct from other features.
16
16
  If a significant feature of the repository is not present in the current feature set, please add it either to a new feature or an existing feature.
17
17
  Before adding a new feature ensure that this feature is distinct from any other feature in the repository, otherwise update an existing feature.
18
18
  When updating an existing feature, ensure that the existing aspects are not omitted in the response, provide the full feature spec.
@@ -1,19 +1,19 @@
1
- Extract and condense the most valuable and impactful technical details from the supplied crawl result. Focus on information that delivers substantial user value and addresses core implementation needs.
2
- Before adding a new document, ensure that this document is distinct from any other document in the library, otherwise update an existing document. Prioritize content that directly enhances the product's primary purpose rather than superficial or redundant information.
1
+ Extract and condense the technical details from the supplied crawl result that are relevant to the mission.
2
+ Before adding a new document, ensure that this document is distinct from any other document in the library, otherwise update an existing document.
3
3
  The document name should be one or two words in SCREAMING_SNAKECASE.
4
4
 
5
- You should extract a section from the sources file to create the document. Each document should contain high-value, actionable content that solves real implementation problems. Focus on:
5
+ You should extract a section from the sources file to create the document. Each document should contain actionable technical content. Focus on:
6
6
 
7
7
  1. A normalised extract of the crawled content containing:
8
- a. The most impactful key technical points that directly enable implementation, not summaries of them
9
- b. A focused table of contents listing the specific technical topics that provide the greatest practical value
10
- c. The actual detailed information for each item in the table of contents, prioritizing content that enables immediate application
11
- 2. A supplementary details section containing the essential technical specifications and implementation details that complement the crawled content and address core functionality needs
8
+ a. The key technical points that directly enable implementation, not summaries of them
9
+ b. A focused table of contents listing the specific technical topics covered
10
+ c. The actual detailed information for each item in the table of contents
11
+ 2. A supplementary details section containing the technical specifications and implementation details that complement the crawled content
12
12
  3. A reference details section containing the critical API specifications, complete SDK method signatures with parameters
13
13
  and return types, exact implementation patterns, specific configuration options with their values
14
14
  and effects, concrete best practices with implementation examples, step-by-step troubleshooting procedures, and
15
- detailed instructional material. Focus on specifications that deliver substantial user value. Do not describe what specifications exist, include the actual specifications themselves.
16
- 4. A detailed digest containing the most valuable technical content from the source section in SOURCES.md and the date when the
15
+ detailed instructional material. Do not describe what specifications exist, include the actual specifications themselves.
16
+ 4. A detailed digest containing the technical content from the source section in SOURCES.md and the date when the
17
17
  content was retrieved (current date)
18
18
  5. Attribution information and data size obtained during crawling
19
19
 
@@ -24,8 +24,7 @@ Don't use any quote escape sequences in the normalised extract.
24
24
  Generally, the whole document might need to be extracted and stored as JSON so be careful to avoid any JSON escape
25
25
  sequences in any part of the document. Use spacing to make it readable and avoid complex Markdown formatting.
26
26
 
27
- For the normalised extract, extract the most valuable technical information from the crawled data and present it in a condensed,
28
- directly usable format that solves real implementation problems. Focus on high-impact content that enables immediate application.
29
- Do not describe what information exists, include the actual information itself. The content must be specific, technical,
30
- and immediately applicable to core functionality needs. Each item in the table of contents must have the essential
31
- technical details that thoroughly explain the implementation while prioritizing content that delivers substantial user value.
27
+ For the normalised extract, extract the technical information from the crawled data and present it in a condensed,
28
+ directly usable format.
29
+ Do not describe what information exists, include the actual information itself. The content must be specific and technical.
30
+ Each item in the table of contents must have the technical details that thoroughly explain the implementation.
@@ -1,13 +1,13 @@
1
- Please review the GitHub issue and determine if it should be enhanced, closed or if no operation is needed. Focus on issues that deliver substantial user value and address core functionality needs.
1
+ Please review the GitHub issue and determine if it should be enhanced, closed or if no operation is needed.
2
2
 
3
- If the issue is relevant to the mission statement and features and provides significant value by enhancing the product's primary purpose:
3
+ If the issue is relevant to the mission statement and features:
4
4
 
5
5
  1. Decide if the issue should be refined, closed or if no operation is needed.
6
- 2. Update the issue description with testable acceptance criteria that validate the delivery of measurable user value
7
- 3. Enhance the issue by adding relevant library documents as issue comments that support implementation of high-impact solutions
6
+ 2. Update the issue description with testable acceptance criteria derived from MISSION.md. Include ALL of: implementation, tests matching MISSION.md acceptance criteria, website updates, docs/evidence, and README. The issue should ask for mission complete — if the entire mission can be accomplished in a single transform, the acceptance criteria should cover everything. Only scope down if the mission is genuinely too large for one pass.
7
+ 3. Enhance the issue by adding relevant library documents as issue comments that support implementation.
8
8
 
9
- If the issue is irrelevant to the mission statement or features, or does not deliver substantial user value by addressing real problems:
9
+ If the issue is irrelevant to the mission statement or features:
10
10
 
11
- 1. Set the action to close the issue and supply an appropriate comment explaining why it doesn't align with the focus on high-impact, core functionality.
11
+ 1. Set the action to close the issue and supply an appropriate comment explaining why it doesn't advance the mission.
12
12
 
13
- Input validation issues that don't directly affect core functionality should be considered low value, and in particular, issues mentioning handling of NaN are probably worthless and should be closed. Prioritize issues that solve real problems rather than those focused on superficial improvements or excessive validation.
13
+ Input validation issues that don't advance the mission should be closed, and in particular, issues mentioning handling of NaN are probably worthless and should be closed.
@@ -1,5 +1,12 @@
1
- Does the combination source file, test file, website files, README file and dependencies file show a solution
2
- with a reasonable likelihood of including a high-impact resolution to the following issue? Evaluate whether the solution delivers substantial user value, addresses core functionality needs, and directly enhances the product's primary purpose rather than implementing superficial improvements or excessive validation.
1
+ Does the combination source file, test file, website files, README file and dependencies file resolve the following issue? Check that the solution satisfies the issue's acceptance criteria and moves the mission toward complete.
2
+
3
+ If the mission could have been fully accomplished in this transform but the solution only partially addresses it, note this gap and suggest a follow-up issue for the remaining work.
4
+
5
+ When reviewing, check that:
6
+ - Tests and implementation are consistent — test expectations must match what the code actually returns (casing, types, formats)
7
+ - Tests match the acceptance criteria in MISSION.md — the mission is the source of truth
8
+ - If tests expect different values than the code produces, create an issue to fix the mismatch
9
+
3
10
  Note: The repository has a website in `src/web/` that uses the JS library. When reviewing, check that website files are updated alongside library changes.
4
11
 
5
12
  When reviewing, also check that evidence artifacts exist under `docs/` for implemented features.
@@ -2,7 +2,7 @@ You are the supervisor of an autonomous coding repository. Your job is to advanc
2
2
 
3
3
  ## Priority Order
4
4
 
5
- 1. **Create issues when the backlog is low** — if fewer than 3 open issues exist, create at least 1 new issue from the features list or mission before dispatching workflows. The pipeline stalls without issues to work on. Always include descriptive titles and the `automated` label.
5
+ 1. **Always strive for mission complete** — every action you take should aim to finish the mission. Create one comprehensive issue that targets the entire mission (all acceptance criteria, tests, website, docs, README). Only create a second issue if the first transform couldn't complete everything, and scope it to the remaining work. Do not create issues just to fill a quota.
6
6
  2. **Dispatch transform when ready issues exist** — transform is where code gets written. Always prefer it over maintain when there are open issues with the `ready` label.
7
7
  3. **Dispatch review after transform** — when recent workflow runs show a transform completion, dispatch review to close resolved issues and add `ready` labels to new issues. This keeps the pipeline flowing.
8
8
  4. **Fix failing PRs** — dispatch fix-code for any PR with failing checks (include pr-number).
@@ -12,12 +12,12 @@ You are the supervisor of an autonomous coding repository. Your job is to advanc
12
12
 
13
13
  1. **Check what's already in progress** — don't duplicate work. If the workflow is already running, don't dispatch another.
14
14
  2. **Prioritise code generation** — the goal is working code. Prefer actions that produce code (dev-only, fix) over metadata (maintain, label).
15
- 3. **Keep the issue pipeline full** — the biggest bottleneck is running out of open issues. Proactively create issues when capacity allows.
15
+ 3. **Right-size the work** — break the mission into chunks just big enough to reliably deliver. One comprehensive issue is better than many small ones. Only create a follow-up issue when the previous transform has landed and gaps remain.
16
16
  4. **Respect limits** — don't create issues beyond the WIP limit shown in the context. Don't dispatch workflows that will fail due to missing prerequisites.
17
17
 
18
18
  ## When to use each action
19
19
 
20
- - **github:create-issue** — When open issues < WIP limit. Derive the issue title from unimplemented features or mission goals. Always include relevant labels (`automated`, `enhancement`).
20
+ - **github:create-issue** — When open issues < WIP limit. Create comprehensive issues that ask for maximum implementation in a single transform. Each issue should request: implementation code, matching tests, website updates, docs/evidence, and README changes. The first issue should aim to deliver the entire mission (all acceptance criteria, tests, website, docs). If a follow-up issue is needed, it should address whatever the first transform didn't complete. Always include relevant labels (`automated`, `enhancement`).
21
21
  - **dispatch:agentic-lib-workflow | mode: dev-only | issue-number: \<N\>** — When there are open issues with the `ready` label and no workflow is currently running.
22
22
  - **dispatch:agentic-lib-workflow | mode: review-only** — After observing a recent transform completion, or when there are unenhanced issues needing the `ready` label.
23
23
  - **dispatch:agentic-lib-workflow | mode: maintain-only** — When features are below their limit AND no maintain appears in the last 3 workflow runs.
@@ -16,7 +16,7 @@
16
16
  "author": "",
17
17
  "license": "MIT",
18
18
  "dependencies": {
19
- "@xn-intenton-z2a/agentic-lib": "^7.1.68"
19
+ "@xn-intenton-z2a/agentic-lib": "^7.1.69"
20
20
  },
21
21
  "devDependencies": {
22
22
  "@vitest/coverage-v8": "^4.0.18",