@probelabs/visor 0.1.105 → 0.1.107

package/README.md

@@ -65,6 +65,7 @@ steps:  # or 'checks' (legacy, both work identically)
 ```
 
 Tip: Pin releases for stability, e.g. `uses: probelabs/visor@v1`.
+For latest changes, use `uses: probelabs/visor@nightly`. The `@main` ref is maintained for compatibility but may change frequently and is not recommended for production.
 
 ## Requirements
 
@@ -120,11 +121,29 @@ See full options and examples: [docs/NPM_USAGE.md](docs/NPM_USAGE.md)
 Additional guides:
 
 - fail conditions: [docs/fail-if.md](docs/fail-if.md)
-- forEach behavior and dependent propagation: [docs/foreach-dependency-propagation.md](docs/foreach-dependency-propagation.md)
+- forEach behavior and dependent propagation (including outputs_raw and history precedence): [docs/foreach-dependency-propagation.md](docs/foreach-dependency-propagation.md)
+- Failure routing and `on_finish` (with outputs_raw in routing JS): [docs/failure-routing.md](docs/failure-routing.md)
 - timeouts and provider units: [docs/timeouts.md](docs/timeouts.md)
+- execution limits (run caps for safety): [docs/limits.md](docs/limits.md)
 - output formatting limits and truncation controls: [docs/output-formatting.md](docs/output-formatting.md)
 - live execution visualizer and control API: [docs/debug-visualizer.md](docs/debug-visualizer.md)
 
+## 🧪 Integration Tests
+
+Write and run integration tests for your Visor config in YAML. No network, built‑in GitHub fixtures, strict by default, and great CLI output.
+
+- Getting started: [docs/testing/getting-started.md](docs/testing/getting-started.md)
+- DSL reference: [docs/testing/dsl-reference.md](docs/testing/dsl-reference.md)
+- Flows: [docs/testing/flows.md](docs/testing/flows.md)
+- Fixtures & mocks: [docs/testing/fixtures-and-mocks.md](docs/testing/fixtures-and-mocks.md)
+- Assertions: [docs/testing/assertions.md](docs/testing/assertions.md)
+- Cookbook: [docs/testing/cookbook.md](docs/testing/cookbook.md)
+- CLI & reporters: [docs/testing/cli.md](docs/testing/cli.md)
+- CI integration: [docs/testing/ci.md](docs/testing/ci.md)
+- Troubleshooting: [docs/testing/troubleshooting.md](docs/testing/troubleshooting.md)
+
+Note: examples use descriptive step names (e.g., `extract-facts`, `validate-fact`) to illustrate patterns. These are not built‑ins; the test runner works with whatever steps you define in `.visor.yaml`.
+
 ## 🧩 Core Concepts (1 minute)
 
 - Check – unit of work (`security`, `performance`).
@@ -399,6 +418,36 @@ steps:
 
 Learn more: [docs/dependencies.md](docs/dependencies.md). See also: [forEach dependency propagation](docs/foreach-dependency-propagation.md)
 
+Quick example (outputs_raw):
+
+```yaml
+version: "2.0"
+checks:
+  list:
+    type: command
+    exec: echo '["a","b","c"]'
+    forEach: true
+
+  summarize:
+    type: script
+    depends_on: [list]
+    content: |
+      const arr = outputs_raw['list'] || [];
+      return { total: arr.length };
+
+  branch-by-size:
+    type: script
+    depends_on: [list]
+    content: 'return true'
+    on_success:
+      goto_js: |
+        return (outputs_raw['list'] || []).length >= 3 ? 'after' : null;
+
+  after:
+    type: log
+    message: bulk mode reached
+```
+
 ## 🔄 Failure Routing (Auto-fix Loops)
 
 Automatically remediate failures and re‑run steps using config‑driven routing:
@@ -623,9 +672,10 @@ Learn more: [docs/http.md](docs/http.md)
 
 ## 🔧 Pluggable Architecture
 
-Mix providers (`ai`, `mcp`, `http`, `http_client`, `log`, `command`, `github`, `claude-code`) or add your own.
+Mix providers (`ai`, `mcp`, `http`, `http_client`, `log`, `command`, `script`, `github`, `claude-code`) or add your own.
 
 - **Command Provider**: Execute shell commands with templating and security - [docs/command-provider.md](docs/command-provider.md)
+- **Script Provider**: Run JavaScript in a secure sandbox - [docs/script.md](docs/script.md)
 - **MCP Provider**: Call MCP tools directly via stdio, SSE, or HTTP transports - [docs/mcp-provider.md](docs/mcp-provider.md)
 - **MCP Tools for AI**: Enhance AI providers with MCP context - [docs/mcp.md](docs/mcp.md)
 - **Custom Providers**: Build your own providers - [docs/pluggable.md](docs/pluggable.md)
@@ -663,6 +713,9 @@ Learn more: [CONTRIBUTING.md](CONTRIBUTING.md)
 - Failure conditions schema: [docs/failure-conditions-schema.md](docs/failure-conditions-schema.md)
 - Failure conditions implementation notes: [docs/failure-conditions-implementation.md](docs/failure-conditions-implementation.md)
 - Recipes and practical examples: [docs/recipes.md](docs/recipes.md)
+- ForEach outputs and precedence (outputs vs outputs_raw vs history): [docs/foreach-dependency-propagation.md](docs/foreach-dependency-propagation.md)
+- Failure routing and on_finish aggregation (with outputs_raw in routing): [docs/failure-routing.md](docs/failure-routing.md)
+- Example config using outputs_raw: examples/outputs-raw-basic.yaml
 
 ## 📄 License
 
@@ -692,3 +745,13 @@ steps:
 ```
 
 See docs: docs/github-ops.md
+## Integration Tests
+
+Visor ships a YAML‑native integration test runner so you can describe user flows, mocks, and assertions alongside your config.
+
+- Start here: docs/testing/getting-started.md
+- CLI details: docs/testing/cli.md
+- Fixtures and mocks: docs/testing/fixtures-and-mocks.md
+- Assertions reference: docs/testing/assertions.md
+
+Example suite: defaults/.visor.tests.yaml

package/action.yml

@@ -33,7 +33,7 @@ inputs:
     default: 'true'
   
   checks:
-    description: 'Comma-separated list of checks to run (security,performance,style,architecture,all)'
+    description: 'Comma-separated list of checks to run (security,performance,architecture,quality,all)'
     required: false
     default: 'all'
   

package/defaults/code-refiner.yaml

@@ -0,0 +1,114 @@
+version: "1.0"
+
+# Example: Code Refiner
+#
+# Re-uses the existing defaults/code-review.yaml as a nested workflow step (via
+# `config:`), then iteratively applies fixes using claude-code until no
+# critical/error issues remain. Uses declarative transitions with pure JS.
+
+steps:
+  # 1) Run code-review as a nested workflow step
+  run-review:
+    type: workflow
+    # Re-use existing config directly (resolved from workingDirectory)
+    config: defaults/code-review.yaml
+    criticality: policy
+    on: [pr_opened, pr_updated]
+    # If the review discovered blocking issues, mark this check failed so
+    # routing goes to the fix step via on_fail. Base this strictly on the
+    # nested workflow's output object (no implicit globals).
+    fail_if: "(output?.hasErrors === true) || ((output?.issues?.length ?? 0) > 0)"
+    # Guarantee that the workflow output contract is present for downstream logic
+    guarantee: "typeof output.hasErrors === 'boolean' && Array.isArray(output.issues)"
+    on_fail:
+      goto: fix-with-claude
+    on_success:
+      goto: post-verified
+
+  # 2) Attempt automated fixes with Claude Code
+  fix-with-claude:
+    type: claude-code
+    criticality: internal
+    if: "outputs['run-review']?.hasErrors === true"
+    # Minimal post-exec contract for internal steps
+    guarantee: typeof output.content === 'string' && output.content.length > 0
+    prompt: |
+      You are an expert code refiner.
+      Apply targeted, minimal changes to resolve blocking issues from the latest review.
+
+      Review results (JSON):
+      {{ outputs['run-review'] | json }}
+
+      Please prioritize fixing issues with severity "critical" or "error" first.
+
+      Rules:
+      - Keep diffs minimal; avoid broad refactors.
+      - Preserve behavior and tests unless the issue requires updating them.
+      - Prefer local fixes near the reported lines.
+      - Add/adjust tests when necessary.
+
+      When finished, summarize the changes you made.
+
+    # After fixes, re-run the review; routing loop budget protects from infinity
+    on_success:
+      goto: run-review
+
+  # 3) Final confirmation step once no blocking issues remain
+  post-verified:
+    type: log
+    group: summary
+    if: "outputs['run-review']?.hasErrors === false"
+    message: |
+      ✅ Code Refiner complete. No critical/error issues remain in the latest review.
+
+tests:
+  defaults:
+    strict: true
+    ai_provider: mock
+    fail_on_unexpected_calls: true
+  fixtures: []
+
+  cases:
+    - name: code-refiner-clean-pass
+      description: |
+        Nested workflow (code-review) runs as a step via `config:` and produces no blocking issues.
+        The refiner should skip the fix step and proceed directly to post-verified.
+      event: pr_opened
+      fixture: gh.pr_open.minimal
+      mocks:
+        # Black-box mock for the workflow step output
+        run-review:
+          hasErrors: false
+          issues: []
+      expect:
+        calls:
+          - step: run-review
+            exactly: 1
+          - step: post-verified
+            exactly: 1
+        no_calls:
+          - step: fix-with-claude
+
+    - name: code-refiner-fix-loop
+      description: |
+        First review finds blocking issues → fix-with-claude runs → second review is clean → post-verified.
+      event: pr_opened
+      fixture: gh.pr_open.minimal
+      mocks:
+        # First run: hasErrors -> triggers fix; Second run: clean -> post-verified
+        run-review[]:
+          - hasErrors: true
+            issues:
+              - { severity: error, ruleId: "security/test", message: "Mock issue", file: "a.ts", line: 1 }
+          - hasErrors: false
+            issues: []
+        # Mock Claude Code to satisfy guarantee
+        fix-with-claude: { content: "Applied targeted fixes" }
+      expect:
+        calls:
+          - step: run-review
+            exactly: 2
+          - step: fix-with-claude
+            exactly: 1
+          - step: post-verified
+            exactly: 1

package/defaults/{.visor.yaml → code-review.yaml}

@@ -1,69 +1,37 @@
 version: "1.0"
 
-# Default Visor configuration - provides comprehensive code analysis out-of-the-box
-# Uses mock provider for CI compatibility when no AI API keys are configured
-# Users can override this by creating their own .visor.yaml in their project root
-
-# Global AI provider settings - users should configure their preferred provider
-# For CI testing, use --provider mock CLI flag instead
+# Extracted code review steps for reuse and composition
+outputs:
+  - name: issues
+    description: Aggregated issues from review steps
+    value_js: |
+      const values = Object.values(outputs || {});
+      const all = [];
+      for (const v of values) {
+        const arr = (v && Array.isArray(v.issues)) ? v.issues : [];
+        if (arr.length) all.push(...arr);
+      }
+      return all;
 
-# Run up to 4 steps in parallel for faster execution
-max_parallelism: 4
+  - name: hasErrors
+    description: True if any critical or error issues exist
+    value_js: |
+      for (const v of Object.values(outputs || {})) {
+        const arr = (v && Array.isArray(v.issues)) ? v.issues : [];
+        if (arr.some(i => i && (i.severity === 'critical' || i.severity === 'error'))) return true;
+      }
+      return false;
 
-# Global fail condition - fail if critical or error severity issues are found
-fail_if: "output.issues && output.issues.some(i => i.severity === 'critical' || i.severity === 'error')"
 
-# Workflow steps (formerly 'checks' - both keys are supported for backward compatibility)
 steps:
-  # AI-powered release notes generation - manual execution only for release workflows
-  release-notes:
-    type: ai
-    group: release
-    schema: plain
-    prompt: |
-      Generate professional release notes for version {{ env.TAG_NAME }} of this project.
-
-      Analyze the git commits since the last release:
-      ```
-      {{ env.GIT_LOG }}
-      ```
-
-      And the file changes summary:
-      ```
-      {{ env.GIT_DIFF_STAT }}
-      ```
-
-      Create release notes with these sections:
-
-      ## 🚀 What's New in {{ env.TAG_NAME }}
-
-      ### ✨ New Features
-      List any new features added (look for feat: commits)
-
-      ### 🐛 Bug Fixes
-      List any bugs fixed (look for fix: commits)
-
-      ### 📈 Improvements
-      List any improvements or refactoring (look for refactor:, perf:, chore:, build: commits)
-
-      ### 🔥 Breaking Changes
-      List any breaking changes if present (look for BREAKING CHANGE or ! in commits)
-
-      ### 📊 Statistics
-      - Number of commits since last release
-      - Number of contributors involved
-      - Number of files changed
-
-      Keep descriptions concise and user-friendly. Focus on what changed from a user perspective, not implementation details.
-      Use present tense and action-oriented language. Group similar changes together.
-    on: [manual]
-
   # PR overview with intelligent analysis - runs first to establish context
   overview:
     type: ai
     group: overview
-    schema: overview
+    on: [pr_opened, pr_updated]
     prompt: |
+        PR Title: {{ pr.title }}
+
         You are generating PR overview, to help owners of the repository to understand what this PR is above, and help reviewer to point to the right parts of the code. First you should provide detailed but concise description, mentioning all the changes.
 
         ## Files Changed Analysis
@@ -90,13 +58,14 @@ steps:
         - Do not change or re-suggest labels on PR update events; the repository applies labels only on `pr_opened`.
 
         Be concise, specific, and actionable. Avoid praise or celebration.
-    on: [pr_opened, pr_updated]
+    schema: overview
 
   # Security analysis - Critical for all projects
   security:
     type: ai
     group: review
-    schema: code-review
+    on: [pr_opened, pr_updated]
+    depends_on: [overview]
     prompt: |
         Based on our overview discussion, please perform a comprehensive security analysis of the code changes.
 
@@ -136,14 +105,14 @@ steps:
         - **error**: Security issues that must be fixed before production (XSS, path traversal, weak crypto, missing auth checks)
         - **warning**: Security concerns that should be addressed (verbose errors, missing rate limiting, insecure defaults)
         - **info**: Security best practices and hardening suggestions (defense in depth, additional validation)
-    depends_on: [overview]
-    on: [pr_opened, pr_updated]
+    schema: code-review
 
   # Architecture analysis - Ensures sound design and avoids over-engineering
   architecture:
     type: ai
     group: review
-    schema: code-review
+    on: [pr_opened, pr_updated]
+    depends_on: [overview]
     prompt: |
         Building on our overview analysis, evaluate the architectural decisions and design patterns.
 
@@ -188,14 +157,14 @@ steps:
         - **error**: Significant architectural problems (over-engineering, unnecessary special cases, violation of core patterns, missed reuse opportunities)
         - **warning**: Architectural concerns that should be addressed (minor over-abstraction, could be simplified, inconsistent patterns)
         - **info**: Architectural suggestions and alternative approaches (simpler patterns available, potential for future reuse)
-    depends_on: [overview]
-    on: [pr_opened, pr_updated]
+    schema: code-review
 
   # Performance analysis - Important for all applications
   performance:
     type: ai
     group: review
-    schema: code-review
+    on: [pr_opened, pr_updated]
+    depends_on: [overview]
     prompt: |
         Building on our overview analysis, now review the code changes for performance issues.
 
@@ -233,14 +202,14 @@ steps:
         - **error**: Significant performance problems affecting user experience (O(n²) in critical path, N+1 queries, blocking I/O)
         - **warning**: Performance concerns that should be optimized (inefficient algorithms, missing indexes, unnecessary operations)
         - **info**: Performance best practices and optimization opportunities (caching suggestions, async improvements)
-    depends_on: [overview]
-    on: [pr_opened, pr_updated]
+    schema: code-review
 
   # Code quality and maintainability
   quality:
     type: ai
     group: review
-    schema: code-review
+    on: [pr_opened, pr_updated]
+    depends_on: [overview]
     prompt: |
         Building on our overview discussion, evaluate the code quality and maintainability.
 
@@ -303,164 +272,4 @@ steps:
         - **error**: Quality problems that significantly impact maintainability (no error handling, high complexity, severe coupling, tests with magic numbers)
         - **warning**: Quality concerns that should be addressed (missing tests, code duplication, poor naming, unclear test expectations)
         - **info**: Best practices and improvement suggestions (refactoring opportunities, documentation improvements, test clarity)
-    depends_on: [overview]
-    on: [pr_opened, pr_updated]
-
-  # Code style and formatting analysis
-  style:
-    type: ai
-    group: review
     schema: code-review
-    prompt: |
-        Building on our overview discussion, analyze the code style and formatting consistency.
-
-        Review the code changes shown in the `<full_diff>` or `<commit_diff>` sections, considering the files listed in `<files_summary>`.
-
-        ## Style Assessment Areas
-        **Code Formatting & Consistency:**
-        - Indentation and spacing consistency
-        - Naming conventions adherence
-        - Code organization and structure
-        - Comment style and documentation
-
-        **Language-Specific Style Guidelines:**
-        - Adherence to language style guides (PEP 8, ESLint, etc.)
-        - Import/require statement organization
-        - Variable and function naming patterns
-        - Code readability and clarity
-
-        **Team Standards:**
-        - Consistency with existing codebase patterns
-        - Formatting tool configuration compliance
-        - Documentation standards adherence
-        - Code comment quality and completeness
-
-        Focus on style improvements that enhance code readability and maintainability based on the overview analysis.
-
-        ## Severity Guidelines
-        Use the following severity levels appropriately:
-        - **critical**: Never use for style issues (style issues are never critical)
-        - **error**: Major style violations that significantly harm readability (completely inconsistent formatting, misleading names)
-        - **warning**: Style inconsistencies that should be fixed (mixed conventions, unclear naming, formatting issues)
-        - **info**: Style suggestions and minor improvements (spacing, comment formatting, optional conventions)
-    depends_on: [overview]
-    on: [pr_opened, pr_updated]
-
-  # Apply labels based on overview tags — runs only on PR open (GitHub environments only)
-  apply-overview-labels:
-    type: github
-    tags: [github]
-    depends_on: [overview]
-    on: [pr_opened]
-    op: labels.add
-    values:
-      - "{{ outputs.overview.tags.label | default: '' | safe_label }}"
-      - "{{ outputs.overview.tags['review-effort'] | default: '' | prepend: 'review/effort:' | safe_label }}"
-    value_js: |
-      return values.filter(v => typeof v === 'string' && v.trim().length > 0);
-
-  # Issue Assistant (issues only) — triage-quality prompt from main branch, structured output
-  issue-assistant:
-    type: ai
-    group: dynamic  # New issue triage posts a standalone comment
-    schema: issue-assistant
-    prompt: |
-        You are an intelligent GitHub issue assistant for the {{ event.repository.fullName }} repository. Your role is to provide professional, knowledgeable assistance when a NEW issue is opened.
-
-        Return ONE JSON object (no prose outside JSON) that validates the `issue-assistant` schema with:
-        - `text`: write a clear, well-structured markdown reply that welcomes the reporter, shows understanding, and provides next steps. Use sections and bullets where helpful.
-        - `intent`: must be "issue_triage" for this flow.
-        - `labels` (optional): array of labels that would help organization for this new issue.
-
-        Use this triage rubric (adopted from our main prompt):
-        1) Categorize the issue - choose from: bug, chore, documentation, enhancement, feature, question, wontfix, invalid, duplicate
-        2) Assess priority (low/medium/high/urgent)
-        3) Estimate complexity (trivial/simple/moderate/complex)
-        4) Recommend labels from the categories above
-        5) Identify potential areas affected or relevant documentation
-        6) Provide an initial response with clarifying questions if needed
-
-        Response style:
-        - Professional and welcoming
-        - Start by acknowledging what you understand from the issue report
-        - Clearly state what you're confident about based on the information provided
-        - Identify what is unclear or missing, and explicitly ask follow-up questions to help with debugging
-        - When information is incomplete, ask specific questions that would help diagnose the issue
-        - Provide actionable guidance and clear next steps
-        - Use natural markdown formatting; include code snippets where useful
-        - Be honest about what you know and what you don't know
-        - NEVER make promises about timelines, release dates, or team commitments
-        - NEVER say things like "we'll pick this up", "will be included in upcoming release", or "we will post updates"
-        - Focus on technical analysis and helpful information rather than commitments
-    on: [issue_opened]
-
-  # Comment Assistant (comments only) — intent detection and reply
-  comment-assistant:
-    type: ai
-    group: dynamic
-    schema: issue-assistant
-    command: "visor"
-    prompt: |
-        You are the GitHub comment assistant for {{ event.repository.fullName }}. Respond to user comments on issues or PR discussion threads.
-
-        Return ONE JSON object (no prose outside JSON) that validates the `issue-assistant` schema with:
-        - `text`: a concise, helpful markdown reply to the latest comment.
-        - `intent`: choose one: "comment_reply" (normal reply) or "comment_retrigger" (pick this ONLY when the user explicitly asks to re-run checks OR explicitly asks to disable some checks).
-        - `labels`: omit for comments (do not include).
-
-        Rules:
-        - Never suggest rerun/disable unless asked explicitly.
-        - If asked to disable any check(s), set `intent` = "comment_retrigger" and in `text` acknowledge the request and say the checks will be re-run; DO NOT propose slash/directive comments.
-        - Stay technical, direct, and specific; add code snippets or links when helpful.
-        - When answering questions, acknowledge what you can answer confidently based on the context provided
-        - If you need more information to provide a complete answer, ask specific follow-up questions
-        - Be honest when you don't know something or can't find the answer in the available context
-        - If the question requires information not available in the PR/issue context, clearly state what's missing
-        - Provide partial answers when possible, and indicate what additional information would help give a complete response
-    on: [issue_comment]
-    on_success:
-      goto_js: |
-        const intent = (typeof output === 'object' && output) ? output.intent : undefined;
-        const isComment = (event && event.name) ? (event.name == 'issue_comment') : true;
-        const allowed = typeof hasMinPermission === 'function' ? hasMinPermission('MEMBER') : true;
-        return (isComment && allowed && intent === 'comment_retrigger') ? 'overview' : null
-      goto_event: pr_updated
-
-  # Apply labels to new issues based on assistant output (GitHub-only)
-  apply-issue-labels:
-    type: github
-    tags: [github]
-    depends_on: [issue-assistant]
-    on: [issue_opened]
-    op: labels.add
-    value_js: |
-      try {
-        const issueAssistant = outputs['issue-assistant'];
-        const labels = Array.isArray(issueAssistant?.labels) ? issueAssistant.labels : [];
-        // Sanitize labels: keep [A-Za-z0-9:/], collapse repeated '/'
-        return labels
-          .map(v => (v == null ? '' : String(v)))
-          .map(s => s.replace(/[^A-Za-z0-9:\/]/g, '').replace(/\/{2,}/g, '/'))
-          .filter(s => s.length > 0);
-      } catch (error) {
-        log('Error processing issue labels:', error);
-        return [];
-      }
-
-  # External origin labelling for PRs and Issues
-  external-label:
-    type: github
-    tags: [github]
-    on: [pr_opened, issue_opened]
-    if: "!isMember() && !isContributor()"
-    op: labels.add
-    values:
-      - "external"
-
-  # Retrigger noop removed — comment-assistant schedules overview directly
-
-output:
-  pr_comment:
-    format: markdown
-    group_by: check
-    collapse: true

package/defaults/override.yaml

@@ -0,0 +1,52 @@
+version: "1.0"
+
+# Bring in the full default Visor workflow (which itself includes code-review.yaml)
+include:
+  - ./visor.yaml
+
+# Override exactly one of the imported code-review steps using appendPrompt
+steps:
+  security:
+    appendPrompt: |
+      Additionally, search for any hard-coded credentials (API keys, tokens,
+      passwords) or secrets in diffs and configuration files. If found, mark
+      them as critical and recommend using a secret manager or environment
+      variables instead.
+  # Add a new lightweight code-review step to demonstrate extending the suite
+  readability:
+    type: ai
+    group: review
+    on: [pr_opened, pr_updated]
+    depends_on: [overview]
+    prompt: |
+      Perform a lightweight readability review of the proposed changes.
+      Focus on:
+      - Clear, intention-revealing naming
+      - Helpful comments (avoid redundant ones)
+      - Function length and cohesion
+      - Early returns to reduce nesting
+      - Eliminate dead code and commented-out blocks
+    schema: code-review
+
+tests:
+  defaults:
+    strict: false
+    ai_provider: mock
+  cases:
+    - name: override-appendPrompt-security
+      event: pr_opened
+      fixture: gh.pr_open.minimal
+      mocks:
+        overview:
+          text: "Overview body"
+          tags: { label: feature, review-effort: 2 }
+        security: { issues: [] }
+      expect:
+        calls:
+          - step: security
+            exactly: 1
+        prompts:
+          - step: security
+            contains:
+              - "hard-coded credentials"
+              - "secret manager"