mustflow 1.18.16 → 1.31.0

package/templates/default/locales/es/.mustflow/skills/security-privacy-review/SKILL.md

@@ -1,116 +0,0 @@
----
-mustflow_doc: skill.security-privacy-review
-locale: es
-canonical: false
-revision: 1
-lifecycle: mustflow-owned
-authority: procedure
-name: security-privacy-review
-description: Apply this skill when code, configuration, docs, templates, logs, telemetry, credentials, or data flows affect secrets, personal data, authentication, authorization, retention, or external disclosure.
-metadata:
-  mustflow_schema: "1"
-  mustflow_kind: procedure
-  pack_id: mustflow.core
-  skill_id: mustflow.core.security-privacy-review
-  command_intents:
-    - changes_status
-    - changes_diff_summary
-    - docs_validate_fast
-    - test_release
-    - mustflow_check
----
-
-# Security and Privacy Review
-
-<!-- mustflow-section: purpose -->
-## Purpose
-
-Catch security, privacy, and disclosure risks introduced by ordinary code, documentation, template, configuration, logging, or reporting changes.
-
-<!-- mustflow-section: use-when -->
-## Use When
-
-- A change touches authentication, authorization, sessions, admin behavior, tenant boundaries, personal data, secrets, tokens, credentials, API keys, or private files.
-- A change adds or modifies logging, telemetry, diagnostics, receipts, reports, caches, generated state, retention, redaction, export, or external transmission.
-- Documentation, templates, examples, tests, or final reports mention sensitive data handling, privacy behavior, secret handling, or user-identifying data.
-- A diff could expose data through filenames, paths, command output, screenshots, generated artifacts, package contents, or public docs.
-
-<!-- mustflow-section: do-not-use-when -->
-## Do Not Use When
-
-- The task needs a concrete abuse-case regression test; use `security-regression-tests` for that part.
-- The task is only dependency availability, package version freshness, or artifact packaging without sensitive data.
-- The task is a general security checklist with no changed boundary, data flow, or disclosure surface to inspect.
-
-<!-- mustflow-section: required-inputs -->
-## Required Inputs
-
-- Changed files, diff summary, and the user goal.
-- Sensitive data, actor, trust boundary, storage, logging, retention, export, or external disclosure surfaces involved.
-- Existing project rules for secrets, privacy, generated state, public docs, package contents, and command output.
-- Relevant command-intent contract entries for status, diff, docs, release, or mustflow validation.
-
-<!-- mustflow-section: preconditions -->
-## Preconditions
-
-- The task matches the Use When conditions and does not match the Do Not Use When exclusions.
-- Required inputs are available, or missing inputs can be reported without guessing.
-- Higher-priority instructions and `.mustflow/config/commands.toml` have been checked for the current scope.
-
-<!-- mustflow-section: allowed-edits -->
-## Allowed Edits
-
-- Add or tighten redaction, masking, omission, retention, disclosure, or documentation wording when the changed surface justifies it.
-- Remove sensitive-looking sample values from docs, fixtures, templates, logs, reports, and final output when they are not required.
-- Mark unknown privacy or secret-handling behavior as unverified instead of claiming it is safe.
-- Do not invent compliance claims, privacy guarantees, secret scanning results, or audit coverage.
-
-<!-- mustflow-section: procedure -->
-## Procedure
-
-1. Identify the sensitive surface: secret, personal data, actor, permission, storage location, log, generated artifact, package file, public document, or external recipient.
-2. Decide whether the change creates, stores, reads, transforms, logs, exports, deletes, or reports sensitive information.
-3. Check whether the changed surface is public, packaged, generated, cached, retained, user-visible, or sent outside the repository boundary.
-4. Verify that examples, fixtures, screenshots, command outputs, and final reports do not expose real-looking secrets or unnecessary personal data.
-5. Prefer omission or minimal metadata over masking when the sensitive value is not needed for the user to understand the result.
-6. If the change affects an authorization or abuse boundary, activate `security-regression-tests` for test selection instead of folding test generation into this review.
-7. Run the narrowest configured verification that covers the changed docs, templates, package, or mustflow contract.
-
-<!-- mustflow-section: postconditions -->
-## Postconditions
-
-- Sensitive data and disclosure surfaces have been identified or explicitly reported as unknown.
-- Public and packaged surfaces do not include unnecessary secrets, personal data, or misleading privacy guarantees.
-- The final report names remaining unverified security or privacy risks without revealing sensitive values.
-
-<!-- mustflow-section: verification -->
-## Verification
-
-Use configured oneshot command intents when available:
-
-- `changes_status`
-- `changes_diff_summary`
-- `docs_validate_fast`
-- `test_release`
-- `mustflow_check`
-
-Use a narrower configured test, build, or documentation intent when it better proves the changed sensitive surface.
-
-<!-- mustflow-section: failure-handling -->
-## Failure Handling
-
-- If a sensitive value appears in command output, stop copying it and summarize the issue without the value.
-- If the project lacks enough context to confirm privacy or secret handling, report the uncertainty and avoid claiming safety.
-- If a package, generated artifact, or public doc includes sensitive data, remove or redact it before continuing unrelated work.
-- If verification requires unavailable scanners or live systems, report the missing check and the remaining risk.
-
-<!-- mustflow-section: output-format -->
-## Output Format
-
-- Sensitive surfaces reviewed
-- Disclosure or retention paths checked
-- Redaction, omission, or wording changes made
-- Related security-regression test need
-- Command intents run
-- Skipped checks and reasons
-- Remaining security or privacy risk

package/templates/default/locales/es/.mustflow/skills/security-regression-tests/SKILL.md

@@ -1,131 +0,0 @@
----
-mustflow_doc: skill.security-regression-tests
-locale: es
-canonical: false
-revision: 1
-lifecycle: mustflow-owned
-authority: procedure
-name: security-regression-tests
-description: Apply this skill when security-sensitive code or behavior changes need abuse-case regression tests.
-metadata:
-  mustflow_schema: "1"
-  mustflow_kind: procedure
-  pack_id: mustflow.core
-  skill_id: mustflow.core.security-regression-tests
-  command_intents:
-    - test
-    - test_related
-    - test_audit
-    - lint
-    - build
----
-
-# Security Regression Tests
-
-<!-- mustflow-section: purpose -->
-## Purpose
-
-Convert security-sensitive behavior changes into safe negative tests that preserve defensive expectations without turning the task into vulnerability scanning, exploit development, or penetration testing.
-
-<!-- mustflow-section: use-when -->
-## Use When
-
-- Authentication, authorization, session, CSRF, rate-limit, admin, payment, credit, subscription, personal-data, or tenant-boundary behavior changes.
-- Input validation, output encoding, file upload, path handling, webhook callback, redirect, or external URL handling changes.
-- A bug fix closes an abuse case and the fix needs a regression test to prevent reintroduction.
-- A review identifies a concrete security-sensitive boundary that can be expressed as a deterministic test.
-
-<!-- mustflow-section: do-not-use-when -->
-## Do Not Use When
-
-- The task is only a general security review, dependency audit, static analysis request, or policy discussion.
-- The repository lacks enough application context to identify the real protected resource, actor, trust boundary, or existing test harness.
-- The only available output would be a generic test such as "prevents XSS" without a specific route, component, serializer, or data flow.
-- The test would require real external services, live attack traffic, credential guessing, destructive input, or unsafe payload collection.
-- The user explicitly asks not to add or propose tests.
-
-<!-- mustflow-section: required-inputs -->
-## Required Inputs
-
-- The changed behavior, diff, route, component, handler, data model, or bug fix that creates the security-sensitive boundary.
-- The relevant actors, ownership rules, trust boundary, allowed and denied state combinations, and expected status or error behavior.
-- Existing test framework, fixtures, factories, mocks, request helpers, and naming conventions.
-- `.mustflow/config/commands.toml` entries for test, audit, lint, and build-related intents.
-- Any project context or public contract that defines privacy, authorization, upload, callback, payment, or tenant rules.
-
-<!-- mustflow-section: preconditions -->
-## Preconditions
-
-- The task matches the Use When conditions and does not match the Do Not Use When exclusions.
-- Required inputs are available, or missing inputs can be reported without guessing.
-- Higher-priority instructions and `.mustflow/config/commands.toml` have been checked for the current scope.
-- The test can be written as a defensive expectation without teaching an exploit recipe or contacting unsafe targets.
-
-<!-- mustflow-section: allowed-edits -->
-## Allowed Edits
-
-- Keep edits within the scope described by this skill, the user request, and the matching route in `.mustflow/skills/INDEX.md`.
-- Prefer existing test files, fixtures, factories, mocks, and helper APIs before adding new test structure.
-- Do not broaden command permission, invent project facts, introduce external scanners, add offensive payload corpora, or change unrelated workflow files.
-
-<!-- mustflow-section: procedure -->
-## Procedure
-
-1. Identify the protected boundary: actor, resource, operation, trust boundary, and expected defensive outcome.
-2. Classify the abuse case using project-specific facts, not broad labels alone:
-   - unauthorized actor or cross-tenant access
-   - invalid ownership or privilege escalation
-   - unsafe input shape, size, encoding, path, or MIME mismatch
-   - unsafe output rendering or serialization
-   - unsafe external URL, callback, redirect, or server-side request target
-   - payment, credit, coupon, subscription, refund, or entitlement abuse
-   - personal-data or admin-only access leakage
-3. Search for existing tests that already cover the same boundary. Strengthen the existing test when that gives clearer coverage than adding a new one.
-4. Build the smallest safe negative test data: at least one allowed control case when useful, and one denied case that proves the boundary rejects the abuse condition.
-5. Use mocks or local fakes for external requests, uploads, redirects, webhooks, payment providers, and file systems. Do not contact live suspicious endpoints.
-6. Name the test after the defensive expectation, such as `cannot_read_other_users_invoice` or `rejects_private_network_callback_url`.
-7. Keep assertions tied to observable behavior: status code, returned error shape, unchanged database state, missing side effect, sanitized output, or rejected job.
-8. Avoid dumping long exploit strings into the test. Use minimal representative input that proves the validation or boundary rule.
-9. If the project lacks enough context to write a deterministic test, output a concrete test proposal instead of inventing fixtures or behavior.
-
-<!-- mustflow-section: postconditions -->
-## Postconditions
-
-- The expected output can be produced with clear evidence, executed command intents, skipped checks, and remaining risks.
-- Any missing command intent, unknown input, or authority conflict is reported instead of hidden.
-- New tests are justified by a concrete security-sensitive behavior contract, not by a habit of adding tests to every change.
-
-<!-- mustflow-section: verification -->
-## Verification
-
-Use configured oneshot command intents when available:
-
-- `test_related`
-- `test`
-- `test_audit`
-- `lint`
-- `build`
-
-Prefer the narrowest configured test intent that covers the changed boundary. Do not infer missing test, lint, scanner, or build commands. If a relevant intent is unknown or manual-only, report that status and the remaining verification risk.
-
-<!-- mustflow-section: failure-handling -->
-## Failure Handling
-
-- If a generated test fails because the defensive behavior is missing, inspect the nearest production code that owns the boundary before weakening the test.
-- If a generated test fails because fixtures or assumptions are wrong, fix the test setup or report the missing project fact.
-- If the test would require unsafe traffic, real credentials, live external targets, or destructive data, replace it with a local mock-based expectation or a written test proposal.
-- If existing tests already prove the boundary, report the existing coverage rather than adding duplicate cases.
-- If the repository's testing policy requires more evidence before adding tests, report the security-sensitive contract that justifies the test or stop at a proposal.
-
-<!-- mustflow-section: output-format -->
-## Output Format
-
-- Security-sensitive boundary reviewed
-- Abuse case classification
-- Required test data
-- Tests added or strengthened
-- Existing coverage reused
-- Suspected code location if the test fails
-- Command intents run
-- Skipped command intents and reasons
-- Remaining security or verification risks

package/templates/default/locales/es/.mustflow/skills/skill-authoring/SKILL.md

@@ -1,110 +0,0 @@
----
-mustflow_doc: skill.skill-authoring
-locale: es
-canonical: false
-revision: 3
-lifecycle: mustflow-owned
-authority: procedure
-name: skill-authoring
-description: Apply this skill when creating or maintaining `.mustflow/skills/*/SKILL.md` procedures and `.mustflow/skills/INDEX.md` routes.
-metadata:
-  mustflow_schema: "1"
-  mustflow_kind: procedure
-  pack_id: mustflow.core
-  skill_id: mustflow.core.skill-authoring
-  command_intents:
-    - mustflow_check
-    - docs_validate
----
-
-# Skill Authoring
-
-<!-- mustflow-section: purpose -->
-## Purpose
-
-Create narrow, repeatable mustflow skill procedures without turning skills into broad advice, project context, or command-permission sources.
-
-<!-- mustflow-section: use-when -->
-## Use When
-
-- A `.mustflow/skills/<name>/SKILL.md` file is created, renamed, split, removed, or substantially changed.
-- `.mustflow/skills/INDEX.md` needs a new or updated route for a skill.
-- A skill needs clearer use conditions, exclusion conditions, required inputs, command intent references, verification, or failure handling.
-- A broad prompt, checklist, or outside recommendation needs to be adapted into mustflow's skill format.
-
-<!-- mustflow-section: do-not-use-when -->
-## Do Not Use When
-
-- The task only applies an existing skill to code, docs, tests, context, or assets.
-- The content belongs in `AGENTS.md`, `.mustflow/docs/agent-workflow.md`, `.mustflow/context/PROJECT.md`, or `.mustflow/config/commands.toml`.
-- The proposed skill is broad advice such as "write better code" or "be careful" without a repeatable trigger and procedure.
-- The skill would duplicate project-domain context, authorize commands, install dependencies, or define raw shell commands.
-
-<!-- mustflow-section: required-inputs -->
-## Required Inputs
-
-- The user request and the repeated task the skill should cover.
-- Existing `.mustflow/skills/INDEX.md` and nearby skill documents.
-- `.mustflow/config/commands.toml` command intent names relevant to verification.
-- Any repository evidence showing that the task is repeatable and not better handled by an existing skill.
-- Localization and template metadata when the skill is part of an installed template.
-
-<!-- mustflow-section: preconditions -->
-## Preconditions
-
-- The task matches the Use When conditions and does not match the Do Not Use When exclusions.
-- Required inputs are available, or missing inputs can be reported without guessing.
-- Higher-priority instructions and `.mustflow/config/commands.toml` have been checked for the current scope.
-
-<!-- mustflow-section: allowed-edits -->
-## Allowed Edits
-
-- Keep edits within the scope described by this skill, the user request, and the matching route in `.mustflow/skills/INDEX.md`.
-- Do not broaden command permission, invent project facts, or change unrelated workflow files.
-
-<!-- mustflow-section: procedure -->
-## Procedure
-
-1. Define the smallest repeatable task the skill should cover. If the task is too broad, split it or leave it as repository guidance instead of creating a skill.
-2. Search existing skills before adding a new one. Prefer updating a matching skill over creating overlapping procedures.
-3. Use a stable folder name and matching frontmatter `name`. Set `mustflow_doc` to `skill.<name>`, `metadata.mustflow_schema` to `"1"`, `metadata.mustflow_kind` to `procedure`, `metadata.pack_id` to the package namespace, and `metadata.skill_id` to `<pack_id>.<name>`.
-4. Escribe las secciones estandar: Proposito, Usar Cuando, No Usar Cuando, Entradas Requeridas, Precondiciones, Ediciones Permitidas, Procedimiento, Postcondiciones, Verificacion, Manejo De Fallos y Formato De Salida.
-5. Keep the procedure concrete and bounded. Include what to read, what to change, what to avoid, and what evidence to report.
-6. Reference command intent names only. Do not include raw shell command blocks or claim that the skill authorizes command execution.
-7. Actualiza `.mustflow/skills/INDEX.md` con una ruta compacta que incluya disparador, entrada requerida, alcance de edicion, riesgo, intentos de verificacion y salida esperada.
-8. If the skill is installed by a template, update template manifests, localization metadata, installation docs, package tests, and public docs that list installed files.
-
-<!-- mustflow-section: postconditions -->
-## Postconditions
-
-- The expected output can be produced with clear evidence, executed command intents, skipped checks, and remaining risks.
-- Any missing command intent, unknown input, or authority conflict is reported instead of hidden.
-
-<!-- mustflow-section: verification -->
-## Verification
-
-Use configured oneshot command intents when available:
-
-- `mustflow_check`
-- `docs_validate`
-
-If the skill changes tests or behavior-sensitive template output, also use the relevant configured test or build intents.
-
-<!-- mustflow-section: failure-handling -->
-## Failure Handling
-
-- If `mustflow_check` reports missing sections, metadata drift, unknown command intents, raw shell commands, or command-permission claims, fix the skill contract before changing unrelated files.
-- If two skills overlap, tighten their use and non-use conditions or merge the duplicate procedure.
-- If a needed command intent is missing, record the missing intent instead of inventing a command inside the skill.
-- If translation confidence is low, keep the source skill authoritative and mark translations for review through template metadata.
-
-<!-- mustflow-section: output-format -->
-## Output Format
-
-- Skill files added, updated, renamed, or removed
-- Skill index routes changed
-- Command intents referenced
-- Template or localization metadata updated
-- Command intents run
-- Skipped command intents and reasons
-- Remaining overlap, translation, or validation risks

package/templates/default/locales/es/.mustflow/skills/source-freshness-check/SKILL.md

@@ -1,111 +0,0 @@
----
-mustflow_doc: skill.source-freshness-check
-locale: es
-canonical: false
-revision: 1
-lifecycle: mustflow-owned
-authority: procedure
-name: source-freshness-check
-description: Apply this skill when a task depends on information that may become stale, such as current versions, external docs, prices, dates, schedules, or product behavior.
-metadata:
-  mustflow_schema: "1"
-  mustflow_kind: procedure
-  pack_id: mustflow.core
-  skill_id: mustflow.core.source-freshness-check
-  command_intents:
-    - changes_status
-    - docs_validate_fast
-    - mustflow_check
----
-
-# Source Freshness Check
-
-<!-- mustflow-section: purpose -->
-## Purpose
-
-Prevent stale or unverifiable claims from entering code, documentation, templates, release notes, or final reports.
-
-<!-- mustflow-section: use-when -->
-## Use When
-
-- The task asks for the latest, current, newest, today, yesterday, tomorrow, or a specific recent date.
-- A claim depends on external products, APIs, package versions, pricing, legal rules, schedules, sports, markets, or vendor documentation.
-- Documentation or user-facing text mentions support status, release behavior, command availability, or compatibility that may drift.
-- A source, quote, screenshot, or generated summary may be older than the current task.
-
-<!-- mustflow-section: do-not-use-when -->
-## Do Not Use When
-
-- The fact is purely local to the repository and can be verified from current files.
-- The task is a mechanical edit that does not introduce or preserve time-sensitive claims.
-- The user explicitly provides the source text to use and asks only for formatting or translation.
-
-<!-- mustflow-section: required-inputs -->
-## Required Inputs
-
-- The claim or decision that may become stale.
-- The file, command output, source page, screenshot, or user-provided text that supports the claim.
-- The date or version context when it is visible.
-- Any repository policy about allowed sources, official documentation, or offline work.
-
-<!-- mustflow-section: preconditions -->
-## Preconditions
-
-- The task matches the Use When conditions and does not match the Do Not Use When exclusions.
-- Required inputs are available, or missing inputs can be reported without guessing.
-- Higher-priority instructions and `.mustflow/config/commands.toml` have been checked for the current scope.
-
-<!-- mustflow-section: allowed-edits -->
-## Allowed Edits
-
-- Add or update source-date notes only where they clarify freshness risk.
-- Replace unstable wording such as "latest" with a dated or versioned claim when appropriate.
-- Mark translations or docs for review when the source cannot be verified confidently.
-- Do not invent citations, release dates, compatibility ranges, or vendor behavior.
-
-<!-- mustflow-section: procedure -->
-## Procedure
-
-1. Identify every claim that depends on time, external behavior, or an upstream source.
-2. Prefer the current repository file, official source, declared package metadata, or user-provided source text before secondary summaries.
-3. Capture the freshness boundary: date checked, version checked, release tag, documentation page, or reason the claim is local and stable.
-4. If a claim cannot be refreshed within the allowed tools or command contract, keep the wording conservative and report the unverified source.
-5. Avoid open-ended words such as "latest", "current", or "recent" unless the sentence includes the concrete date or version that makes the claim inspectable.
-6. When editing documentation, keep source notes close to the claim or in the final report rather than adding broad provenance sections.
-7. Run the smallest configured verification that covers the changed files.
-
-<!-- mustflow-section: postconditions -->
-## Postconditions
-
-- Time-sensitive claims are either verified, dated, versioned, or explicitly reported as unverified.
-- Documentation does not imply live freshness when only a snapshot was checked.
-- The final report names skipped refresh checks and any remaining stale-source risk.
-
-<!-- mustflow-section: verification -->
-## Verification
-
-Use configured oneshot command intents when available:
-
-- `changes_status`
-- `docs_validate_fast`
-- `mustflow_check`
-
-Also run the relevant configured test, build, or documentation intent if the refreshed claim changes executable behavior or public documentation.
-
-<!-- mustflow-section: failure-handling -->
-## Failure Handling
-
-- If the requested source cannot be accessed, report the access gap and avoid presenting the claim as current.
-- If sources conflict, prefer the highest-authority source and report the conflict.
-- If the freshness check changes meaning in translated docs, mark the affected translation for review.
-- If checking freshness would require network access or tools outside the current host permissions, stop at the permission boundary and state what remains unchecked.
-
-<!-- mustflow-section: output-format -->
-## Output Format
-
-- Freshness-sensitive claims found
-- Source or version checked
-- Wording changed or claim left conservative
-- Command intents run
-- Skipped source checks and reasons
-- Remaining stale-source risk