@massa-ai/cursor-plugin 1.26.0 → 1.29.0

package/skills/massa-ai/workflows/requirements/requirements-audit.md

@@ -1,12 +1,20 @@
+---
+name: requirements-audit
+description: "Findings-only review of whether a concrete target matches stated requirements without out-of-scope drift; routes correctness, security, and quality findings elsewhere."
+license: MIT
+metadata:
+  version: "1.1.0"
+---
+
 ### Requirements Audit
 
-Use this workflow for findings-only review of whether a concrete target matches stated requirements without out-of-scope drift. Accepted targets include modified files, explicit files/globs, commit ranges, branch comparisons, modules/packages, symbols/classes/functions, feature/runtime flows, explicitly requested whole-repo scope, or an implementation scope packet supplied by `workflows/implementation/implementation-audit.md`.
+Findings-only review of whether a concrete target matches stated requirements without out-of-scope drift. Accepted targets include modified files, explicit files/globs, commit ranges, branch comparisons, modules/packages, symbols/classes/functions, feature/runtime flows, explicitly requested whole-repo scope, or an implementation scope packet supplied by `workflows/implementation/implementation-audit.md`.
 
-Before the first substantive read, load `references/project-context.md` and run the project-context intake sweep for this repository.
+Load `references/project-context.md` (intake sweep) before the first substantive read.
 
-Do not use this workflow for generic correctness bugs, security findings, architecture findings, code quality findings, or test coverage findings. Route correctness bugs to `workflows/bugs/bugs-audit.md` and route the other categories to their dedicated workflows.
+Not for generic correctness bugs, security findings, architecture findings, code quality findings, or test coverage findings. Route correctness bugs to `workflows/bugs/bugs-audit.md` and route the other categories to their dedicated workflows.
 
-This workflow is findings-only. Do not edit code unless the user separately asks for fixes.
+Findings-only: do not edit code unless the user separately asks for fixes.
 
 1. Resolve/reuse `workflowSessionId`: `requirements-[entity]`
 2. Load shared references:
@@ -32,33 +40,8 @@ This workflow is findings-only. Do not edit code unless the user separately asks
    - If the target focus is missing, vague, or too broad, ask for a concrete target from the supported scope types in `references/audit-scope.md`.
    - If requirements source is missing after checking the prompt, PR description, task file, spec, issue text, and repo docs, ask for the requirements source before proceeding.
    - Build the shared scope packet from `references/audit-scope.md` and carry it into the report.
-5. For modified files scope:
-   - Include staged and unstaged tracked files from the working tree.
-   - Include untracked non-generated source, test, fixture, schema, config, and docs files only when they can affect required behavior.
-   - Exclude deleted files unless their deletion can break required behavior, imports, exports, routing, migrations, config, tests, packaging, or documentation contracts.
-   - Exclude generated, dependency, build, log, cache, temporary, and secret paths per repo rules.
-   - Inspect diffs first, then only the surrounding code needed to compare implementation against requirements.
-6. For commit range scope:
-   - If the user supplied explicit commits or a revision range, use that exact range.
-   - If the user asked for commits made by me, resolve author identity from `git config user.email`; if empty, use `git config user.name`.
-   - For branch-relative commit scopes, resolve the branch base from the upstream merge-base first, then fall back in order to `origin/main`, `origin/master`, `main`, and `master`.
-   - If the user asked for commits made by me, review branch-unique commits authored by the resolved identity.
-   - If no explicit range, required author identity, or branch base can be resolved, ask the user for the missing value before proceeding.
-   - Inspect changed files and diffs from those commits, then requirements sources, callers, tests, config, schemas, and docs only as needed.
-7. For codebase area scope:
-   - Require a concrete path, module, package, feature area, or glob.
-   - If the target area is missing, ask for it before proceeding.
-   - Follow the shared retrieval order from `references/codebase-investigation.md` to find entry points, public API, tests, config, docs, and acceptance criteria.
-8. For explicit files/globs, branch comparison, symbol/class/function, feature/flow, or explicitly requested whole-repo scope:
-   - Resolve the target with `references/audit-scope.md` and record the resolution method, base/head when relevant, resolved files, exclusions, requirements source, and freshness timestamp.
-   - For symbol/class/function targets, inspect definitions, call paths, public contracts, tests, config, docs, and requirement links only as needed.
-   - For feature/flow targets, map expected behavior from the requirements source to implementation, tests, docs, and public contracts.
-   - If whole-repo scope is requested, map top-level requirement areas first and report skipped depth checks rather than implying exhaustive coverage.
-9. For implementation parent scope:
-   - Accept the exact scope packet and requirement source from `implementation-audit`.
-   - Do not broaden beyond resolved files, surrounding code, public contracts, tests, config, docs, and requirements needed to verify a claim.
-   - Return compact findings to the parent implementation audit; do not write broad project memories unless explicitly assigned.
-10. Investigation pass. Dispatch `audit-specialist` per `references/agent-orchestration.md` when the scope justifies an isolated read-only subagent:
+5. Resolve the selected branch's mechanics (modified files, commit range, codebase area, explicit-files/branch/symbol/feature/whole-repo, or implementation parent scope) per `references/audit-scope.md` (Lens Audit Scope Resolution Procedure, Requirements row of Per-Lens Scope Deltas). Implementation parent scope additionally carries the requirement source from `implementation-audit`.
+6. Investigation pass. Dispatch `audit-specialist` per `references/agent-orchestration.md` when the scope justifies an isolated read-only subagent:
 
 > **Dispatch: `massa-ai-audit-specialist`** (role: `audit-specialist`) — charter `skills/agents/audit-specialist/SKILL.md`
 > - trigger: large scope, explicit parallel/subagent request, PR subagent invocation, or independent verification of high-impact finding
@@ -75,16 +58,16 @@ This workflow is findings-only. Do not edit code unless the user separately asks
    - Compare implementation and tests against each checklist item.
    - Prioritize missing requirements, contradicted requirements, out-of-scope behavior, changed public contracts, compatibility breaks, incomplete edge cases, and docs or tests that misrepresent delivered behavior.
    - For each candidate finding, record the concrete claim, source evidence, affected requirement, impacted flow, provisional severity, and what would disprove it.
-11. False-positive pass:
+7. False-positive pass:
    - Try to disprove every candidate before reporting it.
    - Check requirement wording, accepted scope changes, ADRs, feature flags, compatibility notes, tests, docs, call paths, and user-provided constraints.
    - Drop candidates disproven by evidence, downgrade candidates with partial mitigation, and mark low-confidence findings explicitly.
-12. Severity rules (apply the countable threshold first, then the qualitative clause):
+8. Severity rules (apply the countable threshold first, then the qualitative clause):
    - `critical`: implementation violates a mandatory requirement in a way that blocks release, causes data loss, breaks auth/privacy, OR affects >10 files; otherwise use the qualitative clause below.
    - `high`: missing or contradictory core requirement, significant out-of-scope behavior, public contract break, or major compatibility regression.
    - `medium`: incomplete edge-case requirement, unclear acceptance gap, recoverable behavior mismatch (<=10 affected files), missing required docs/test coverage around a requirement, or scoped regression.
    - `low`: minor requirement ambiguity, wording mismatch, low-impact out-of-scope behavior, incomplete evidence, or weakly supported concern.
-13. Final report:
+9. Final report:
    - Findings first, ordered by severity: `critical`, `high`, `medium`, `low`.
    - Each finding must use `REQ-<N>` and include the canonical fields from `references/audit-report-io.md`: severity, confidence, requirement source, requirement ID or quote, requirement gap type, file/line, evidence, impact, simplest fix direction, and verification suggestion.
    - If no requirements findings are found, say that clearly and list scope checked, requirement source used, and skipped checks.
@@ -93,11 +76,11 @@ This workflow is findings-only. Do not edit code unless the user separately asks
    - Include the Verification/Test Fidelity Checklist from `references/audit-report-io.md`; tie every `REQ-*` finding or no-finding claim to deterministic sensors, commands/artifacts, results, validation assets, or skipped-check reasons. Model judgment alone cannot satisfy verification/testing all-clear.
    - For direct top-level invocation, use the Plan Mode save rule and canonical report contract from `references/audit-report-io.md` for `audits/requirements/<YYYY-MM-DD requirements-audit>.md`.
    - For implementation audit child invocation, return compact findings to the parent unless the parent explicitly requests saved audit artifacts.
-14. Persist only durable knowledge:
+10. Persist only durable knowledge:
    - Do not persist one-off findings.
    - Persist durable requirements decisions, accepted scope constraints, repeated requirement-drift patterns, or reusable verification recipes after scoring with the Importance Calibration System.
    - Use required tags: `project:<projectId>`, `session:<workflowSessionId>`, `workflow:requirements-audit`, `entity:<entity>`, and one `memory:<tier>` tag.
-15. Complete the Evidence Gate from `references/evidence-gate.md`.
+11. Complete the Evidence Gate from `references/evidence-gate.md`.
 
 ## Examples
 

package/skills/massa-ai/workflows/requirements/requirements-fix.md

@@ -1,12 +1,20 @@
+---
+name: requirements-fix
+description: "Executes fixes from a saved requirements audit report; not for findings-only review or broad feature design when acceptance criteria are missing."
+license: MIT
+metadata:
+  version: "1.1.0"
+---
+
 ### Requirements Fix
 
-Use this workflow only to execute fixes from a requirements audit markdown report.
+Execute fixes from a requirements audit markdown report only.
 
-Before the first substantive read, load `references/project-context.md` and run the project-context intake sweep for this repository.
+Load `references/project-context.md` (intake sweep) before the first substantive read.
 
-Before the first repository mutation, load `references/implementation-delivery.md` for worktree isolation, atomic commits, PR creation, CI watch, and the merge gate, and `references/code-annotation.md` for doc blocks, rationale comments, and test coverage on every created or updated unit. If two consecutive fix attempts fail on the same symptom, stop editing and load `references/root-cause-scripts.md`.
+Before the first repository mutation, load `references/implementation-delivery.md` (delivery chain: worktree, atomic commits, PR, CI watch, merge gate) and `references/code-annotation.md` (doc blocks, rationale, test coverage). After two consecutive failed fixes on one symptom, stop editing and load `references/root-cause-scripts.md`.
 
-Do not use this workflow for findings-only requirements review; route that to `workflows/requirements/requirements-audit.md`. Do not use it for broad feature design when acceptance criteria are missing; route that to `workflows/spec-driven.md`.
+Not for findings-only requirements review — route to `workflows/requirements/requirements-audit.md`. Not for broad feature design when acceptance criteria are missing — route to `workflows/spec-driven.md`.
 
 1. Resolve/reuse `workflowSessionId`: `requirements-fix-[entity]`
 2. Load shared references:
@@ -23,7 +31,7 @@ Do not use this workflow for findings-only requirements review; route that to `w
    - If the user asks for "latest" or gives no path, require a concrete target focus first; do not run the latest requirements report against an unspecified target.
    - Select the latest `audits/requirements/<YYYY-MM-DD requirements-audit>.md` only after target focus is known, using `references/audit-report-io.md`.
    - Stop if no report exists; do not infer findings from conversation history.
-   - Validate the report with `references/audit-report-io.md`: workflow, `ProjectId`, `Target`, `Target Focus`, scope, git base/head, required fields, `REQ-` IDs, requirement source, resolved files or material scope evidence, and current file/line evidence. Stop on invalid, stale, target-drifted, or ambiguous reports before editing.
+   - Validate the report deterministically: `bun skills/massa-ai/scripts/validate_audit_report.ts <path> --family requirements` (`references/audit-report-io.md`, Deterministic Validation, checks `Requirements Source` too); non-zero exit blocks editing. Also confirm resolved files or material scope evidence and current file/line evidence; stop on stale, target-drifted, or ambiguous reports.
 5. Extract actionable findings:
    - Keep findings with concrete `Requirement Source`, `Requirement ID or Quote`, `Requirement Gap Type`, `Location`, `Evidence`, `Impact`, `Simplest Fix Direction`, and `Verification Suggestion`.
    - Ignore ruled-out candidates and no-finding sections.

package/skills/massa-ai/workflows/rfc.md

@@ -1,8 +1,16 @@
+---
+name: rfc
+description: "Use this workflow when a significant technical, process, product, vendor, tool, or policy decision is still open and stakeholders need a structured proposal before committing."
+license: MIT
+metadata:
+  version: "1.1.0"
+---
+
 ### RFC (Request for Comments)
 
-Use this workflow when a significant technical, process, product, vendor, tool, or policy decision is still open and stakeholders need a structured proposal before committing to a direction. Route a finalized architecture decision to `workflows/adr.md`, settled implementation design to `workflows/tdd.md`, and broad requirements-through-delivery work to `workflows/spec-driven.md`.
+Use when a significant technical, process, product, vendor, tool, or policy decision is still open and stakeholders need a structured proposal before committing to a direction. Route a finalized architecture decision to `workflows/adr.md`, settled implementation design to `workflows/tdd.md`, and broad requirements-through-delivery work to `workflows/spec-driven.md`.
 
-Before the first substantive read, load `references/project-context.md` and run the project-context intake sweep for this repository.
+Load `references/project-context.md` (intake sweep) before the first substantive read.
 
 ## Workflow
 

package/skills/massa-ai/workflows/security/security-audit.md

@@ -1,12 +1,20 @@
+---
+name: security-audit
+description: "Findings-only security review workflow for a concrete target; routes generic correctness bugs and other audit categories to their dedicated workflows."
+license: MIT
+metadata:
+  version: "1.1.0"
+---
+
 ### Security Audit
 
-Use this workflow for findings-only security review in a concrete target: modified files, explicit files/globs, commit ranges, branch comparisons, modules/packages, symbols/classes/functions, feature/runtime flows, explicitly requested whole-repo scope, or an implementation scope packet supplied by `workflows/implementation/implementation-audit.md`.
+Findings-only security review scoped to a concrete target: modified files, explicit files/globs, commit ranges, branch comparisons, modules/packages, symbols/classes/functions, feature/runtime flows, explicitly requested whole-repo scope, or an implementation scope packet supplied by `workflows/implementation/implementation-audit.md`.
 
-Before the first substantive read, load `references/project-context.md` and run the project-context intake sweep for this repository.
+Load `references/project-context.md` (intake sweep) before the first substantive read.
 
-Do not use this workflow for generic correctness bugs; route those to `workflows/bugs/bugs-audit.md`. Do not use it for broad architecture, code quality, requirements, or test coverage audits; route those to their dedicated workflows.
+Not for generic correctness bugs — route to `workflows/bugs/bugs-audit.md`. Not for broad architecture, code quality, requirements, or test coverage audits — route to their dedicated workflows.
 
-This workflow is findings-only. Do not edit code unless the user separately asks for fixes.
+Findings-only: do not edit code unless the user separately asks for fixes.
 
 1. Resolve/reuse `workflowSessionId`: `security-[entity]`
 2. Load shared references:
@@ -31,32 +39,8 @@ This workflow is findings-only. Do not edit code unless the user separately asks
    - Implementation parent scope: use only when `workflows/implementation/implementation-audit.md` invokes this workflow with a concrete implementation scope packet.
    - If the target focus is missing, vague, or too broad, ask for a concrete target from the supported scope types in `references/audit-scope.md`.
    - Build the shared scope packet from `references/audit-scope.md` and carry it into the report.
-5. For modified files scope:
-   - Include staged and unstaged tracked files from the working tree.
-   - Include untracked non-generated source, test, fixture, schema, config, and docs files only when they can affect runtime or validation behavior.
-   - Exclude deleted files unless their deletion can break imports, exports, routing, migrations, config, tests, packaging, secrets handling, or policy enforcement.
-   - Exclude generated, dependency, build, log, cache, temporary, and secret paths per repo rules.
-   - Inspect diffs first, then only the surrounding code needed to understand security behavior.
-6. For commit range scope:
-   - If the user supplied explicit commits or a revision range, use that exact range.
-   - If the user asked for commits made by me, resolve author identity from `git config user.email`; if empty, use `git config user.name`.
-   - For branch-relative commit scopes, resolve the branch base from the upstream merge-base first, then fall back in order to `origin/main`, `origin/master`, `main`, and `master`.
-   - If the user asked for commits made by me, review branch-unique commits authored by the resolved identity.
-   - If no explicit range, required author identity, or branch base can be resolved, ask the user for the missing value before proceeding.
-   - Inspect changed files and diffs from those commits, then auth boundaries, callers, tests, config, schemas, and policy definitions only as needed.
-7. For codebase area scope:
-   - Require a concrete path, module, package, feature area, or glob.
-   - If the target area is missing, ask for it before proceeding.
-   - Follow the shared retrieval order from `references/codebase-investigation.md` to find entry points, trust boundaries, policy checks, validators, tests, and adjacent config.
-8. For explicit files/globs, branch comparison, symbol/class/function, feature/flow, or explicitly requested whole-repo scope:
-   - Resolve the target with `references/audit-scope.md` and record the resolution method, base/head when relevant, resolved files, exclusions, and freshness timestamp.
-   - For symbol/class/function targets, inspect definitions, call paths, trust boundaries, validators, policies, tests, config, and schemas only as needed.
-   - For feature/flow targets, trace untrusted input, identity, authorization, validation, persistence, side effects, and logs through the named flow.
-   - If whole-repo scope is requested, map major trust boundaries first and report skipped depth checks rather than implying exhaustive review.
-9. For implementation parent scope:
-   - Accept the exact scope packet from `implementation-audit`; do not broaden beyond resolved files, surrounding code, called auth/validation helpers, config, schemas, and tests needed to verify a security claim.
-   - Return compact findings to the parent implementation audit; do not write broad project memories unless explicitly assigned.
-10. Investigation pass. Dispatch `audit-specialist` per `references/agent-orchestration.md` when the scope justifies an isolated read-only subagent:
+5. Resolve the selected branch's mechanics (modified files, commit range, codebase area, explicit-files/branch/symbol/feature/whole-repo, or implementation parent scope) per `references/audit-scope.md` (Lens Audit Scope Resolution Procedure, Security row of Per-Lens Scope Deltas).
+6. Investigation pass. Dispatch `audit-specialist` per `references/agent-orchestration.md` when the scope justifies an isolated read-only subagent:
 
 > **Dispatch: `massa-ai-audit-specialist`** (role: `audit-specialist`) — charter `skills/agents/audit-specialist/SKILL.md`
 > - trigger: large scope, explicit parallel/subagent request, PR subagent invocation, or independent verification of high-impact finding
@@ -73,17 +57,17 @@ This workflow is findings-only. Do not edit code unless the user separately asks
    - Check authn/authz, object ownership, tenant isolation, input validation, output encoding, secret handling, cryptography use, SSRF/path traversal/injection risks, logging privacy, dependency/config exposure, and security-sensitive tests.
    - For mobile scopes, check secure storage/keychain/keystore use, permission states, deep links and auth guards, push token handling, biometrics, local DB/cache and offline queues, logs/crash reports/screenshots, native bridge payload trust, and backend-mobile contract skew from `references/mobile-context.md`.
    - For each candidate finding, record the concrete claim, source evidence, impacted asset or boundary, likely trigger, provisional severity, and what would disprove it.
-11. False-positive pass:
+7. False-positive pass:
    - Try to disprove every candidate before reporting it.
    - Check guards, framework defaults, policy layers, middleware order, type checks, tests, feature flags, call paths, existing invariants, ADRs, and accepted exceptions.
    - Use official docs or web research only when current external API, framework, or security behavior matters.
    - Drop candidates disproven by evidence, downgrade candidates with partial mitigation, and mark low-confidence findings explicitly.
-12. Severity rules (apply the countable threshold first, then the qualitative clause):
+8. Severity rules (apply the countable threshold first, then the qualitative clause):
    - `critical`: likely auth bypass, privilege escalation, data exfiltration, secret exposure, remote code execution, tenant break, irreversible data corruption, OR affects >10 files; otherwise use the qualitative clause below.
    - `high`: likely missing authorization, injection risk, sensitive data leak, broken security boundary, unsafe deserialization, or severe config exposure.
    - `medium`: real edge-flow security bug, incomplete validation, privacy leak with limited scope (<=10 affected files), weak cryptographic/config practice with plausible exploitation, or meaningful test gap around security logic.
    - `low`: defensive hardening opportunity, low-impact information exposure, incomplete evidence, or weakly supported concern.
-13. Final report:
+9. Final report:
    - Findings first, ordered by severity: `critical`, `high`, `medium`, `low`.
    - Each finding must use `SEC-<N>` and include the canonical fields from `references/audit-report-io.md`: severity, confidence, file/line, evidence, security boundary, asset, trigger or exploit path, negative test direction, simplest fix direction, and verification suggestion.
    - If no security findings are found, say that clearly and list scope checked plus skipped checks.
@@ -92,11 +76,11 @@ This workflow is findings-only. Do not edit code unless the user separately asks
    - Include the Verification/Test Fidelity Checklist from `references/audit-report-io.md`; tie every `SEC-*` finding or no-finding claim to deterministic sensors, commands/artifacts, results, validation assets, or skipped-check reasons. Model judgment alone cannot satisfy verification/testing all-clear.
    - For direct top-level invocation, use the Plan Mode save rule and canonical report contract from `references/audit-report-io.md` for `audits/security/<YYYY-MM-DD security-audit>.md`.
    - For implementation audit child invocation, return compact findings to the parent unless the parent explicitly requests saved audit artifacts.
-14. Persist only durable knowledge:
+10. Persist only durable knowledge:
    - Do not persist one-off findings.
    - Persist repeated security patterns, project-specific security boundaries, accepted exceptions, or reusable verification recipes after scoring with the Importance Calibration System.
    - Use required tags: `project:<projectId>`, `session:<workflowSessionId>`, `workflow:security-audit`, `entity:<entity>`, and one `memory:<tier>` tag.
-15. Complete the Evidence Gate from `references/evidence-gate.md`.
+11. Complete the Evidence Gate from `references/evidence-gate.md`.
 
 ## Examples
 

package/skills/massa-ai/workflows/security/security-fix.md

@@ -1,12 +1,20 @@
+---
+name: security-fix
+description: "Executes fixes from a saved security audit report; not for findings-only security review or generic correctness fixes outside an exploitable path."
+license: MIT
+metadata:
+  version: "1.1.0"
+---
+
 ### Security Fix
 
-Use this workflow only to execute fixes from a security audit markdown report.
+Execute fixes from a security audit markdown report only.
 
-Before the first substantive read, load `references/project-context.md` and run the project-context intake sweep for this repository.
+Load `references/project-context.md` (intake sweep) before the first substantive read.
 
-Before the first repository mutation, load `references/implementation-delivery.md` for worktree isolation, atomic commits, PR creation, CI watch, and the merge gate, and `references/code-annotation.md` for doc blocks, rationale comments, and test coverage on every created or updated unit. If two consecutive fix attempts fail on the same symptom, stop editing and load `references/root-cause-scripts.md`.
+Before the first repository mutation, load `references/implementation-delivery.md` (delivery chain: worktree, atomic commits, PR, CI watch, merge gate) and `references/code-annotation.md` (doc blocks, rationale, test coverage). After two consecutive failed fixes on one symptom, stop editing and load `references/root-cause-scripts.md`.
 
-Do not use this workflow for findings-only security review; route that to `workflows/security/security-audit.md`. Do not use it for generic correctness fixes unless the security report identifies the correctness issue as part of an exploitable path.
+Not for findings-only security review — route to `workflows/security/security-audit.md`. Not for generic correctness fixes unless the security report identifies the correctness issue as part of an exploitable path.
 
 1. Resolve/reuse `workflowSessionId`: `security-fix-[entity]`
 2. Load shared references:
@@ -24,7 +32,7 @@ Do not use this workflow for findings-only security review; route that to `workf
    - If the user asks for "latest" or gives no path, require a concrete target focus first; do not run the latest security report against an unspecified target.
    - Select the latest `audits/security/<YYYY-MM-DD security-audit>.md` only after target focus is known, using `references/audit-report-io.md`.
    - Stop if no report exists; do not infer findings from conversation history.
-   - Validate the report with `references/audit-report-io.md`: workflow, `ProjectId`, `Target`, `Target Focus`, scope, git base/head, required fields, `SEC-` IDs, resolved files or material scope evidence, and current file/line evidence. Stop on invalid, stale, target-drifted, or ambiguous reports before editing.
+   - Validate the report deterministically: `bun skills/massa-ai/scripts/validate_audit_report.ts <path> --family security` (`references/audit-report-io.md`, Deterministic Validation); non-zero exit blocks editing. Also confirm resolved files or material scope evidence and current file/line evidence; stop on stale, target-drifted, or ambiguous reports.
 5. Extract actionable findings:
    - Keep findings with concrete `Security Boundary`, `Asset`, `Location`, `Evidence`, exploit path or trigger, `Negative Test Direction`, `Simplest Fix Direction`, and `Verification Suggestion`.
    - Ignore ruled-out candidates, no-finding sections, and low-confidence hardening ideas unless the user explicitly asks to include them.