docs: Weekly Documentation Update

.claude/commands/create-frontend-release.md

@@ -391,7 +391,7 @@ echo "Last stable release: $LAST_STABLE"
 
 ```bash
 # Trigger the workflow
-gh workflow run version-bump.yaml -f version_type=${VERSION_TYPE}
+gh workflow run release-version-bump.yaml -f version_type=${VERSION_TYPE}
 
 # Workflow runs quickly - usually creates PR within 30 seconds
 echo "Workflow triggered. Waiting for PR creation..."
@@ -443,28 +443,21 @@ echo "Workflow triggered. Waiting for PR creation..."
    gh pr view ${PR_NUMBER} --json labels | jq -r '.labels[].name' | grep -q "Release" || \
      echo "ERROR: Release label missing! Add it immediately!"
    ```
-2. Check for update-locales commits:
-   ```bash
-   # WARNING: update-locales may add [skip ci] which blocks release workflow!
-   gh pr view ${PR_NUMBER} --json commits | grep -q "skip ci" && \
-     echo "WARNING: [skip ci] detected - release workflow may not trigger!"
-   ```
-3. Verify version number in package.json
-4. Review all changed files
-5. Ensure no unintended changes included
-6. Wait for required PR checks:
+2. Verify version number in package.json
+3. Review all changed files
+4. Ensure no unintended changes included
+5. Wait for required PR checks:
    ```bash
    gh pr checks ${PR_NUMBER} --watch
    ```
-7. **FINAL CODE REVIEW**: Release label present and no [skip ci]?
+6. **FINAL CODE REVIEW**: Release label present and no [skip ci]?
 
 ### Step 12: Pre-Merge Validation
 
 1. **Review Requirements**: Release PRs require approval
-2. Monitor CI checks - watch for update-locales
-3. **CRITICAL WARNING**: If update-locales adds [skip ci], the release workflow won't trigger!
-4. Check no new commits to main since PR creation
-5. **DEPLOYMENT READINESS**: Ready to merge?
+2. Monitor CI checks
+3. Check no new commits to main since PR creation
+4. **DEPLOYMENT READINESS**: Ready to merge?
 
 ### Step 13: Execute Release
 

AGENTS.md

@@ -21,7 +21,7 @@ See @docs/guidance/\*.md for file-type-specific conventions (auto-loaded by glob
 - i18n: `src/i18n.ts`,
 - Entry Point: `src/main.ts`.
 - Tests:
-  - unit/component in `tests-ui/` and `src/**/*.test.ts`
+  - unit/component in `src/**/*.test.ts`
   - E2E (Playwright) in `browser_tests/**/*.spec.ts`
 - Public assets: `public/`
 - Build output: `dist/`
@@ -264,7 +264,7 @@ A particular type of complexity is over-engineering, where developers have made
 
 ## Repository Navigation
 
-- Check README files in key folders (tests-ui, browser_tests, composables, etc.)
+- Check README files in key folders (browser_tests, composables, etc.)
 - Prefer running single tests for performance
 - Use --help for unfamiliar CLI tools
 

src/composables/README.md

@@ -85,7 +85,7 @@ The following diagram shows how composables fit into the application architectur
 
 ## Composable Categories
 
-The following tables list ALL composables in the system as of 2025-01-30:
+The following tables list ALL composables in the system as of 2026-01-30:
 
 ### Auth
 

src/stores/README.md

@@ -102,7 +102,7 @@ The following diagram illustrates the store architecture and data flow:
 
 ## Core Stores
 
-The following table lists ALL 46 store instances in the system as of 2025-09-01:
+The following table lists ALL 46 store instances in the system as of 2026-01-29:
 
 ### Main Stores