chore(packmind): nightly artifacts update

.claude/rules/packmind/standard-backend-tests-redaction.md

@@ -3,12 +3,12 @@ name: 'Backend Tests Redaction'
 paths:
   - "**/*.spec.ts"
 alwaysApply: false
-description: 'Enforce Jest backend test conventions in Packmind **/*.spec.ts (verb-first names, behavioral assertions, nested `describe(''when...'')`, one `expect`, `afterEach` cleanup with `datasource.destroy()` and `jest.clearAllMocks()`, `toEqual` for arrays, and `stubLogger()` for typed `PackmindLogger` stubs) to improve readability, consistency, and debuggability while preventing inter-test pollution.'
+description: 'This standard establishes best practices for writing backend tests using Jest in the Packmind monorepo. It focuses on clarity, maintainability, and consistency across test suites by emphasizing behavioral testing, proper test organization, and effective use of testing utilities. Apply these rules when writing or refactoring backend unit tests, integration tests, and service tests to ensure tests remain readable, reliable, and easy to debug.'
 ---
 
 # Standard: Backend Tests Redaction
 
-Enforce Jest backend test conventions in Packmind **/*.spec.ts (verb-first names, behavioral assertions, nested `describe('when...')`, one `expect`, `afterEach` cleanup with `datasource.destroy()` and `jest.clearAllMocks()`, `toEqual` for arrays, and `stubLogger()` for typed `PackmindLogger` stubs) to improve readability, consistency, and debuggability while preventing inter-test pollution. :
+This standard establishes best practices for writing backend tests using Jest in the Packmind monorepo. It focuses on clarity, maintainability, and consistency across test suites by emphasizing behavi... :
 * Avoid asserting on stubbed logger output like specific messages or call counts; instead verify observable behavior or return values
 * Avoid testing that a method is a function; instead invoke the method and assert its observable behavior
 * Avoid testing that registry components are defined; instead test the actual behavior and functionality of the registry methods like registration, retrieval, and error handling

.claude/rules/packmind/standard-changelog.md

@@ -3,12 +3,12 @@ name: 'Changelog'
 paths:
   - "CHANGELOG.MD"
 alwaysApply: false
-description: 'Maintain CHANGELOG.MD using Keep a Changelog format with a top [Unreleased] section linked to HEAD, ISO 8601 dates (YYYY-MM-DD), and per-release comparison links like [X.Y.Z]: https://github.com/PackmindHub/packmind/compare/release/<previous>...release/X.Y.Z to ensure accurate, consistent release documentation and version links.'
+description: 'Maintain a consistent and well-structured CHANGELOG.MD file following the Keep a Changelog format to ensure all releases are properly documented with accurate version links and dates. This standard applies whenever creating or updating the CHANGELOG.MD file in the repository root.'
 ---
 
 # Standard: Changelog
 
-Maintain CHANGELOG.MD using Keep a Changelog format with a top [Unreleased] section linked to HEAD, ISO 8601 dates (YYYY-MM-DD), and per-release comparison links like [X.Y.Z]: https://github.com/PackmindHub/packmind/compare/release/<previous>...release/X.Y.Z to ensure accurate, consistent release documentation and version links. :
+Maintain a consistent and well-structured CHANGELOG.MD file following the Keep a Changelog format to ensure all releases are properly documented with accurate version links and dates. This standard ap... :
 * Ensure all released versions have their corresponding comparison links defined at the bottom of the CHANGELOG.MD file in the format [X.Y.Z]: https://github.com/PackmindHub/packmind/compare/release/<previous>...release/X.Y.Z
 * Format all release dates using the ISO 8601 date format YYYY-MM-DD (e.g., 2025-11-21) to ensure consistent and internationally recognized date representation
 * Maintain an [Unreleased] section at the top of the changelog with its corresponding link at the bottom pointing to HEAD to track ongoing changes between releases

.claude/rules/packmind/standard-compliance-logging-personal-information.md

@@ -3,12 +3,12 @@ name: 'Compliance - Logging Personal Information'
 paths:
   - "**/*.ts"
 alwaysApply: false
-description: 'Enforce masking of personal information in TypeScript logs, using a standard first-6-characters-plus-* format for emails and similar patterns for other identifiers, to protect user privacy, comply with data protection regulations, and reduce security risks when handling user-related log entries.'
+description: 'This standard ensures personal information is not exposed in application logs across all environments (development, staging, and production). Logs are often forwarded to external processors such as Datadog, making it critical to prevent leaking sensitive user data. By masking personal information in logs, we maintain user privacy, comply with data protection regulations, and reduce security risks. This standard applies when logging user-related information, debugging authentication flows, tracking user actions, or handling error scenarios involving personal data.'
 ---
 
 # Standard: Compliance - Logging Personal Information
 
-Enforce masking of personal information in TypeScript logs, using a standard first-6-characters-plus-* format for emails and similar patterns for other identifiers, to protect user privacy, comply with data protection regulations, and reduce security risks when handling user-related log entries. :
+This standard ensures personal information is not exposed in application logs across all environments (development, staging, and production). Logs are often forwarded to external processors such as Da... :
 * Never log personal information in clear text across all log levels. Always mask sensitive data such as emails, phone numbers, IP addresses, and other personally identifiable information before logging.
 * Use the standard masking format of first 6 characters followed by "*" for logging user emails. This ensures consistency across the codebase and makes it easier to audit logs for compliance.
 

.claude/rules/packmind/standard-typescript-good-practices.md

@@ -3,12 +3,12 @@ name: 'Typescript good practices'
 paths:
   - "**/*.ts"
 alwaysApply: false
-description: 'Enforce TypeScript error and DTO conventions by prohibiting Object.setPrototypeOf in custom errors and requiring intersection types (DomainType & { extraField: T }) for presentation DTO enrichment to improve reliability and catch domain-field drift at compile time.'
+description: 'Generic practices that can be applied for all TS code in our app'
 ---
 
 # Standard: Typescript good practices
 
-Enforce TypeScript error and DTO conventions by prohibiting Object.setPrototypeOf in custom errors and requiring intersection types (DomainType & { extraField: T }) for presentation DTO enrichment to improve reliability and catch domain-field drift at compile time. :
+Generic practices that can be applied for all TS code in our app :
 * Do not use `Object.setPrototypeOf` when defining errors.
 * When defining a presentation DTO that enriches a domain type, use an intersection type (`DomainType & { extraField: T }`) instead of manually re-declaring the domain type's fields, so that structural drift is caught at compile time.
 

.claude/skills/packmind-update-playbook/references/create-standard-procedure.md

@@ -21,6 +21,10 @@ The parser expects this exact structure:
 
 Description text here. Explain what this standard covers and why it matters.
 
+## Scope
+
+**/*.ts, **/*.tsx
+
 ## Rules
 
 * Rule 1
@@ -32,9 +36,23 @@ Description text here. Explain what this standard covers and why it matters.
 
 - **No YAML frontmatter** — the file is pure markdown
 - **Only `* ` or `- ` bullet rules are parsed** — `### Rule` subsections are NOT supported by the parser
-- **`## Scope` is NOT parsed** (always returns empty string) — do not include it
 - **Must have at least one real rule** — the parser rejects empty rules and silently filters out the placeholder text "No rules defined yet."
 - The `## Rules` heading is recommended for clarity but technically optional — the parser finds rules from the first `* `/`- ` bullet even without it
+- Any other `## ` sub-heading is not a section: it stays part of the description
+
+## Scope Writing Guidelines
+
+`## Scope` holds the **glob patterns** the standard applies to, so coding agents load it only for matching files. Omit the section when the standard applies everywhere.
+
+- Write **globs, not prose**: `**/*.spec.ts`, never "TypeScript test files"
+- Separate several patterns with commas on one line, or write one `- ` bullet per pattern — both are stored as a comma-separated list
+- Keep patterns anchored on the repository root, as `**/` prefixes rather than absolute paths
+
+```markdown
+## Scope
+
+**/*.spec.ts, **/*.test.ts
+```
 
 ## Rule Writing Guidelines
 

.cursor/rules/packmind/standard-backend-tests-redaction.mdc

@@ -4,7 +4,7 @@ alwaysApply: false
 ---
 # Standard: Backend Tests Redaction
 
-Enforce Jest backend test conventions in Packmind **/*.spec.ts (verb-first names, behavioral assertions, nested `describe('when...')`, one `expect`, `afterEach` cleanup with `datasource.destroy()` and `jest.clearAllMocks()`, `toEqual` for arrays, and `stubLogger()` for typed `PackmindLogger` stubs) to improve readability, consistency, and debuggability while preventing inter-test pollution. :
+This standard establishes best practices for writing backend tests using Jest in the Packmind monorepo. It focuses on clarity, maintainability, and consistency across test suites by emphasizing behavi... :
 * Avoid asserting on stubbed logger output like specific messages or call counts; instead verify observable behavior or return values
 * Avoid testing that a method is a function; instead invoke the method and assert its observable behavior
 * Avoid testing that registry components are defined; instead test the actual behavior and functionality of the registry methods like registration, retrieval, and error handling

.cursor/rules/packmind/standard-changelog.mdc

@@ -4,7 +4,7 @@ alwaysApply: false
 ---
 # Standard: Changelog
 
-Maintain CHANGELOG.MD using Keep a Changelog format with a top [Unreleased] section linked to HEAD, ISO 8601 dates (YYYY-MM-DD), and per-release comparison links like [X.Y.Z]: https://github.com/PackmindHub/packmind/compare/release/<previous>...release/X.Y.Z to ensure accurate, consistent release documentation and version links. :
+Maintain a consistent and well-structured CHANGELOG.MD file following the Keep a Changelog format to ensure all releases are properly documented with accurate version links and dates. This standard ap... :
 * Ensure all released versions have their corresponding comparison links defined at the bottom of the CHANGELOG.MD file in the format [X.Y.Z]: https://github.com/PackmindHub/packmind/compare/release/<previous>...release/X.Y.Z
 * Format all release dates using the ISO 8601 date format YYYY-MM-DD (e.g., 2025-11-21) to ensure consistent and internationally recognized date representation
 * Maintain an [Unreleased] section at the top of the changelog with its corresponding link at the bottom pointing to HEAD to track ongoing changes between releases

.cursor/rules/packmind/standard-compliance-logging-personal-information.mdc

@@ -4,7 +4,7 @@ alwaysApply: false
 ---
 # Standard: Compliance - Logging Personal Information
 
-Enforce masking of personal information in TypeScript logs, using a standard first-6-characters-plus-* format for emails and similar patterns for other identifiers, to protect user privacy, comply with data protection regulations, and reduce security risks when handling user-related log entries. :
+This standard ensures personal information is not exposed in application logs across all environments (development, staging, and production). Logs are often forwarded to external processors such as Da... :
 * Never log personal information in clear text across all log levels. Always mask sensitive data such as emails, phone numbers, IP addresses, and other personally identifiable information before logging.
 * Use the standard masking format of first 6 characters followed by "*" for logging user emails. This ensures consistency across the codebase and makes it easier to audit logs for compliance.
 

.cursor/rules/packmind/standard-typescript-good-practices.mdc

@@ -4,7 +4,7 @@ alwaysApply: false
 ---
 # Standard: Typescript good practices
 
-Enforce TypeScript error and DTO conventions by prohibiting Object.setPrototypeOf in custom errors and requiring intersection types (DomainType & { extraField: T }) for presentation DTO enrichment to improve reliability and catch domain-field drift at compile time. :
+Generic practices that can be applied for all TS code in our app :
 * Do not use `Object.setPrototypeOf` when defining errors.
 * When defining a presentation DTO that enriches a domain type, use an intersection type (`DomainType & { extraField: T }`) instead of manually re-declaring the domain type's fields, so that structural drift is caught at compile time.
 

.cursor/skills/packmind-update-playbook/references/create-standard-procedure.md

@@ -21,6 +21,10 @@ The parser expects this exact structure:
 
 Description text here. Explain what this standard covers and why it matters.
 
+## Scope
+
+**/*.ts, **/*.tsx
+
 ## Rules
 
 * Rule 1
@@ -32,9 +36,23 @@ Description text here. Explain what this standard covers and why it matters.
 
 - **No YAML frontmatter** — the file is pure markdown
 - **Only `* ` or `- ` bullet rules are parsed** — `### Rule` subsections are NOT supported by the parser
-- **`## Scope` is NOT parsed** (always returns empty string) — do not include it
 - **Must have at least one real rule** — the parser rejects empty rules and silently filters out the placeholder text "No rules defined yet."
 - The `## Rules` heading is recommended for clarity but technically optional — the parser finds rules from the first `* `/`- ` bullet even without it
+- Any other `## ` sub-heading is not a section: it stays part of the description
+
+## Scope Writing Guidelines
+
+`## Scope` holds the **glob patterns** the standard applies to, so coding agents load it only for matching files. Omit the section when the standard applies everywhere.
+
+- Write **globs, not prose**: `**/*.spec.ts`, never "TypeScript test files"
+- Separate several patterns with commas on one line, or write one `- ` bullet per pattern — both are stored as a comma-separated list
+- Keep patterns anchored on the repository root, as `**/` prefixes rather than absolute paths
+
+```markdown
+## Scope
+
+**/*.spec.ts, **/*.test.ts
+```
 
 ## Rule Writing Guidelines
 

.github/instructions/packmind-backend-tests-redaction.instructions.md

@@ -3,7 +3,7 @@ applyTo: '**/*.spec.ts'
 ---
 # Standard: Backend Tests Redaction
 
-Enforce Jest backend test conventions in Packmind **/*.spec.ts (verb-first names, behavioral assertions, nested `describe('when...')`, one `expect`, `afterEach` cleanup with `datasource.destroy()` and `jest.clearAllMocks()`, `toEqual` for arrays, and `stubLogger()` for typed `PackmindLogger` stubs) to improve readability, consistency, and debuggability while preventing inter-test pollution. :
+This standard establishes best practices for writing backend tests using Jest in the Packmind monorepo. It focuses on clarity, maintainability, and consistency across test suites by emphasizing behavi... :
 * Avoid asserting on stubbed logger output like specific messages or call counts; instead verify observable behavior or return values
 * Avoid testing that a method is a function; instead invoke the method and assert its observable behavior
 * Avoid testing that registry components are defined; instead test the actual behavior and functionality of the registry methods like registration, retrieval, and error handling

.github/instructions/packmind-changelog.instructions.md

@@ -3,7 +3,7 @@ applyTo: 'CHANGELOG.MD'
 ---
 # Standard: Changelog
 
-Maintain CHANGELOG.MD using Keep a Changelog format with a top [Unreleased] section linked to HEAD, ISO 8601 dates (YYYY-MM-DD), and per-release comparison links like [X.Y.Z]: https://github.com/PackmindHub/packmind/compare/release/<previous>...release/X.Y.Z to ensure accurate, consistent release documentation and version links. :
+Maintain a consistent and well-structured CHANGELOG.MD file following the Keep a Changelog format to ensure all releases are properly documented with accurate version links and dates. This standard ap... :
 * Ensure all released versions have their corresponding comparison links defined at the bottom of the CHANGELOG.MD file in the format [X.Y.Z]: https://github.com/PackmindHub/packmind/compare/release/<previous>...release/X.Y.Z
 * Format all release dates using the ISO 8601 date format YYYY-MM-DD (e.g., 2025-11-21) to ensure consistent and internationally recognized date representation
 * Maintain an [Unreleased] section at the top of the changelog with its corresponding link at the bottom pointing to HEAD to track ongoing changes between releases

.github/instructions/packmind-compliance-logging-personal-information.instructions.md

@@ -3,7 +3,7 @@ applyTo: '**/*.ts'
 ---
 # Standard: Compliance - Logging Personal Information
 
-Enforce masking of personal information in TypeScript logs, using a standard first-6-characters-plus-* format for emails and similar patterns for other identifiers, to protect user privacy, comply with data protection regulations, and reduce security risks when handling user-related log entries. :
+This standard ensures personal information is not exposed in application logs across all environments (development, staging, and production). Logs are often forwarded to external processors such as Da... :
 * Never log personal information in clear text across all log levels. Always mask sensitive data such as emails, phone numbers, IP addresses, and other personally identifiable information before logging.
 * Use the standard masking format of first 6 characters followed by "*" for logging user emails. This ensures consistency across the codebase and makes it easier to audit logs for compliance.
 

.github/instructions/packmind-typescript-good-practices.instructions.md

@@ -3,7 +3,7 @@ applyTo: '**/*.ts'
 ---
 # Standard: Typescript good practices
 
-Enforce TypeScript error and DTO conventions by prohibiting Object.setPrototypeOf in custom errors and requiring intersection types (DomainType & { extraField: T }) for presentation DTO enrichment to improve reliability and catch domain-field drift at compile time. :
+Generic practices that can be applied for all TS code in our app :
 * Do not use `Object.setPrototypeOf` when defining errors.
 * When defining a presentation DTO that enriches a domain type, use an intersection type (`DomainType & { extraField: T }`) instead of manually re-declaring the domain type's fields, so that structural drift is caught at compile time.
 

.github/skills/packmind-update-playbook/references/create-standard-procedure.md

@@ -21,6 +21,10 @@ The parser expects this exact structure:
 
 Description text here. Explain what this standard covers and why it matters.
 
+## Scope
+
+**/*.ts, **/*.tsx
+
 ## Rules
 
 * Rule 1
@@ -32,9 +36,23 @@ Description text here. Explain what this standard covers and why it matters.
 
 - **No YAML frontmatter** — the file is pure markdown
 - **Only `* ` or `- ` bullet rules are parsed** — `### Rule` subsections are NOT supported by the parser
-- **`## Scope` is NOT parsed** (always returns empty string) — do not include it
 - **Must have at least one real rule** — the parser rejects empty rules and silently filters out the placeholder text "No rules defined yet."
 - The `## Rules` heading is recommended for clarity but technically optional — the parser finds rules from the first `* `/`- ` bullet even without it
+- Any other `## ` sub-heading is not a section: it stays part of the description
+
+## Scope Writing Guidelines
+
+`## Scope` holds the **glob patterns** the standard applies to, so coding agents load it only for matching files. Omit the section when the standard applies everywhere.
+
+- Write **globs, not prose**: `**/*.spec.ts`, never "TypeScript test files"
+- Separate several patterns with commas on one line, or write one `- ` bullet per pattern — both are stored as a comma-separated list
+- Keep patterns anchored on the repository root, as `**/` prefixes rather than absolute paths
+
+```markdown
+## Scope
+
+**/*.spec.ts, **/*.test.ts
+```
 
 ## Rule Writing Guidelines