Feat security

.codex/framework-version-recap.md

@@ -67,7 +67,7 @@ Versions were checked against the installed Composer packages, `composer.json`,
 
 - Before `1.0.0`, update the current baseline migration instead of growing a long development migration chain.
 - Keep entities, baseline migration, tests, docs, and class map aligned when database shape changes.
-- Package/module migrations may be planned as validated package contributions, but execution should remain core-owned.
+- Extension migrations may be planned as validated extension contributions, but execution should remain core-owned.
 
 ## Twig 3.27 Notes
 
@@ -76,7 +76,7 @@ Versions were checked against the installed Composer packages, `composer.json`,
 - Do not call old internal Twig extension functions such as `twig_escape_filter()` directly. Use runtime APIs such as `EscaperRuntime` where lower-level escaping is genuinely needed.
 - Do not pass `Twig\Template` where public APIs expect `TemplateWrapper`.
 - Keep templates small; move behavior to Twig extensions, components, or services only when the boundary is clear.
-- Use TwigBundle `paths`, `form_themes`, globals, and strict variable settings intentionally for package/theme/template work.
+- Use TwigBundle `paths`, `form_themes`, globals, and strict variable settings intentionally for extension/theme/template work.
 
 ## Tailwind CSS v4 And TailwindBundle Notes
 

.codex/skills/audit-pr-readiness/SKILL.md

@@ -0,0 +1,78 @@
+---
+name: audit-pr-readiness
+description: Run the repository PR-readiness audit before marking a branch or feature slice ready for review. Use when the user explicitly asks for PR readiness, ready-for-review preparation, final pre-PR audit, filling the PR template, or checking whether a branch is ready to submit. Do not use for ordinary code review, review-finding fixes, or broad local branch review unless readiness sign-off is requested.
+---
+
+# Audit PR Readiness
+
+Use this skill to prepare or audit a branch against the repository PR-readiness expectations. This is not a substitute for code review; use `local-code-review` for a complete bug-finding pass and `fix-review-findings` for supplied review comments.
+
+## Required Sources
+
+Before auditing, read:
+
+- `AGENTS.md`, especially `PR Readiness Audits`
+- `.github/PULL_REQUEST_TEMPLATE.md`
+- `dev/WORKLOG.md`
+- relevant changed docs, drafts, manuals, tests, and class-map entries
+
+For the two PR-template references, use these sources directly:
+
+- `#57`: fetch GitHub issue `aavion/studio#57` and use it as the primary source for project-rules, architecture, naming, and documentation drift expectations.
+- `#109`: fetch GitHub issue `aavion/studio#109` and use it as the primary source for codebase readability, naming, hierarchy, class map, frontend structure, and test-suite clarity.
+
+Do not copy the PR checklist into this skill as a second source of truth. Always use `.github/PULL_REQUEST_TEMPLATE.md` as the checklist basis.
+
+## Workflow
+
+1. Determine the review base and changed scope.
+2. Read the current PR template and turn each checkbox into an evidence-backed audit item.
+3. Inspect the branch diff and affected runtime surfaces for each applicable item.
+4. Run or confirm the required verification commands:
+   - `bin/phpunit`
+   - `bin/jstest`
+   - `bin/lint`
+   - focused commands for changed surfaces when full suites do not cover them well
+5. Check documentation alignment:
+   - `README.md`
+   - `dev/draft/*.md`
+   - `dev/CLASSMAP.md`
+   - `dev/WORKLOG.md`
+   - `dev/manual/*.md`
+   - `docs/*.md`
+6. Check translation and user-facing copy alignment when copy changed.
+7. Check setup/init/CI, cross-platform behavior, disabled-feature fallbacks, process/env handling, and extension/API/live route boundaries when touched.
+8. Capture follow-ups in `dev/WORKLOG.md`'s To-Do section when they are real but not appropriate for the current branch.
+9. Fill or update the PR template with honest checkboxes. Leave unchecked anything not actually audited or verified.
+
+## Evidence Standard
+
+- A checked box needs evidence from code inspection, docs inspection, tests, linting, rendering, command output, or an explicit "not applicable" reason.
+- Do not mark a checklist item complete because similar work was done earlier in the branch.
+- If a command was run outside the current session by the user, record it as user-reported unless you also ran it.
+- If a full suite was skipped, state why and list the focused substitute checks.
+
+## Output
+
+Return a PR-ready note based on the project template:
+
+```md
+## Summary
+
+## Testing
+
+## Documentation
+
+## Additional Checks
+
+## Linked Issues / Discussions
+
+## Review Notes
+```
+
+Also summarize:
+
+- small readiness fixes made
+- skipped checks or proof gaps
+- follow-ups recorded in `dev/WORKLOG.md`
+- whether the branch is ready, blocked, or ready with caveats

.codex/skills/bump-version-number/SKILL.md

@@ -0,0 +1,67 @@
+---
+name: bump-version-number
+description: Bump the project or extension version in this repository. Use when the user explicitly asks to raise, bump, set, or update the version number of the root project or a specific extension/package. Do not use for dependency-only updates, release-note drafting, or general package maintenance unless a project or extension version bump is requested.
+---
+
+# Bump Version Number
+
+Use this skill when the user asks to bump the root project version or the version of a specific extension. Treat the manifest as the source of truth.
+
+## Version Target
+
+1. Identify the intended target:
+   - root project: the root `.manifest`
+   - extension: the requested extension manifest, usually under `extensions/{slug}/.manifest` or in the extension repository
+2. If the user provides an explicit version, use that exact version.
+3. If no explicit version is provided:
+   - patch version `+1` for small changes, fixes, review fixes, docs-maintenance bumps, and routine compatibility updates
+   - minor version `+1` for larger feature slices or contract-visible feature work
+   - major version `+1` only after explicit user instruction and a brief confirmation of intent
+4. Preserve the existing version format and manifest style.
+
+## Dependency And Compatibility Checks
+
+After changing the version:
+
+1. Resolve known manifest dependencies that reference the bumped project or extension.
+2. Report dependency constraint conflicts immediately instead of silently widening them.
+3. Update internal dependency constraints only when the new version clearly requires it or the user requested it.
+4. Prefer dynamic tests that read from manifests over static assertions pinned to a concrete version.
+5. If a test would fail only because it hardcodes the old version, update that assertion to compare against the manifest value.
+
+## External Update Awareness
+
+Check for available external updates and report safely applicable candidates. Do not update external dependencies unless the user asks for dependency updates.
+
+Run:
+
+```bash
+COMPOSER_MEMORY_LIMIT=256M bin/composer outdated
+bin/console importmap:outdated
+```
+
+If either command cannot run, report the reason.
+
+## Verification
+
+Run the full suites after the version bump unless the user explicitly narrows verification:
+
+```bash
+bin/phpunit
+bin/jstest
+bin/lint
+```
+
+If full suites are too slow, blocked, or already user-reported, say exactly what was run and what remains unverified.
+
+## Output
+
+Summarize:
+
+- old version and new version
+- manifest path changed
+- dependency conflicts or compatible dependency references found
+- external update candidates from Composer/importmap checks
+- static version assertions converted to manifest-derived expectations
+- verification results
+

.codex/skills/fix-review-findings/SKILL.md

@@ -0,0 +1,58 @@
+---
+name: fix-review-findings
+description: Fix one or more concrete review findings in this repository. Use when the user provides review comments, PR findings, inline review feedback, Cloud Review findings, or local review findings and explicitly asks Codex to fix or address them. Do not use for broad branch reviews, PR-readiness audits, or ordinary feature implementation without supplied findings.
+---
+
+# Fix Review Findings
+
+Use this skill to address supplied review findings with code changes. This is a fix workflow, not a discovery review.
+
+## Required Sources
+
+Before editing, read:
+
+- `AGENTS.md`, especially `Review Finding Fixes`
+- `dev/WORKLOG.md`
+- the cited files, tests, docs, and adjacent code paths for each finding
+- all user comments, maintainer replies, product decisions, policy decisions, and requested scope limits attached to or near the supplied findings
+
+Use `local-code-review` only when the user separately asks for a complete local branch or PR review. Use `audit-pr-readiness` only when the user asks for a PR-readiness audit.
+
+## Workflow
+
+1. Restate the findings briefly and deduplicate shared root causes.
+2. Match each finding with any user or maintainer comments. Treat explicit user decisions as binding for the fix direction unless they conflict with higher-priority safety or project rules.
+3. Do not implement a fix the user rejected. If a comment marks a finding as intentional, policy-driven, or out of scope, document that decision or record the requested follow-up instead of changing behavior.
+4. For each root cause, restate the concrete invariant, attacker or actor input when relevant, closest control or broken control, sink or state transition, impact, and preconditions.
+5. Trace the affected boundary from source to sink. Before editing, establish that the reported weakness is concretely reachable in the checked-out code; if it is already fixed or invalid, prove that instead of patching a nearby concern.
+6. Inspect adjacent and analogous paths that share the same policy, validator, resolver, route family, lifecycle step, storage boundary, contribution type, cleanup/rollback behavior, wrapper, or dangerous sink.
+7. Decide whether the finding is valid, invalid, already fixed, an explicit product decision, or a follow-up.
+8. Reproduce, encode, or otherwise pin the issue before fixing when feasible. Prefer a focused failing test or realistic-interface reproduction; if runtime proof is disproportionate, document the static proof and gap.
+9. For valid findings, place the smallest central fix that covers all affected paths and follows the user's scope comments.
+10. Add or update focused regression coverage for the failing path and any adjacent path changed by the fix. Include positive coverage for legitimate behavior that must continue to work.
+11. Re-check the original source/control/sink path after the fix and search nearby bypasses or equivalent call paths that might avoid the new control.
+12. Update docs, worklog, class map, translations, or follow-up notes only when the fix changes the documented contract or relevant callable map.
+13. Run focused verification while developing, then a broader relevant slice before finishing.
+14. If the user asks for separate commits, commit each logical fix separately with an imperative message.
+
+## Fix Discipline
+
+- Do not turn a review fix into a broad redesign.
+- Do not hide larger or behavior-changing follow-ups inside a narrow fix; record them in `dev/WORKLOG.md`.
+- Do not report success for a partially fixed finding. State residual risk or skipped verification clearly.
+- Do not revert unrelated user or collaborator changes.
+- Prefer structured `Message`, `WorkflowResult`, and domain-owned message catalogues where runtime feedback is needed.
+- Do not weaken authentication, authorization, tenant isolation, input validation, sandboxing, logging, auditability, or lifecycle rollback semantics to make a finding or test pass.
+- Treat setup errors, missing generated files, missing dependencies, or slow validation commands as evidence to investigate with bounded effort, not as immediate proof that runtime validation is impossible.
+- Do not claim the original issue is fixed until the changed code and the original vulnerable path or broken invariant have both been checked.
+
+## Output
+
+When done, summarize:
+
+- findings addressed and status
+- commits created, if any
+- verification commands and results
+- intentionally deferred or rejected findings, with the reason
+- how the original path was shown closed, or the exact proof gap if runtime validation was not feasible
+- remaining worktree state if not clean