@ryuenn3123/agentic-senior-core 1.9.0 → 1.9.2

package/.agent-context/skills/frontend/ui-architecture.md

@@ -1,128 +1,128 @@
-# Component Architecture and State Management
-
-**Tier:** EXPERT | **Source:** awesome-copilot (smart/dumb) + minimax (design systems) + antigravity (React patterns)
-
-## Purpose
-
-UI architecture decides how state, behavior, and presentation are split. Good structure reduces re-render churn, keeps component boundaries stable, and makes features easier to test.
-
-## Part 1: Smart and Dumb Separation
-
-A smart component owns data flow, side effects, and orchestration. A dumb component renders input and emits events.
-
-```javascript
-function PaymentFormContainer() {
-  const [amount, setAmount] = useState('');
-  const [status, setStatus] = useState('idle');
-  const [errorMessage, setErrorMessage] = useState(null);
-
-  const handleSubmit = async (submittedAmount) => {
-    setStatus('loading');
-    try {
-      const response = await fetch('/api/payments', {
-        method: 'POST',
-        body: JSON.stringify({ amount: submittedAmount })
-      });
-
-      if (!response.ok) {
-        throw new Error('Payment request failed');
-      }
-
-      setStatus('success');
-    } catch (caughtError) {
-      setErrorMessage(caughtError.message);
-      setStatus('error');
-    }
-  };
-
-  return (
-    <PaymentFormView
-      amount={amount}
-      isLoading={status === 'loading'}
-      errorMessage={errorMessage}
-      onAmountChange={setAmount}
-      onSubmit={handleSubmit}
-    />
-  );
-}
-```
-
-```javascript
-function PaymentFormView({ amount, isLoading, errorMessage, onAmountChange, onSubmit }) {
-  return (
-    <form onSubmit={(event) => { event.preventDefault(); onSubmit(amount); }}>
-      <input
-        value={amount}
-        onChange={(event) => onAmountChange(event.target.value)}
-        disabled={isLoading}
-      />
-      <button disabled={isLoading}>
-        {isLoading ? 'Processing' : 'Pay'}
-      </button>
-      {errorMessage ? <p>{errorMessage}</p> : null}
-    </form>
-  );
-}
-```
-
-## Part 2: State Ownership Rules
-
-Use the smallest useful state scope.
-
-- Local component state: form fields, toggles, ephemeral UI state.
-- Shared UI state: theme, sidebar state, modal visibility.
-- Server state: remote data, caching, invalidation, refetching.
-- Derived state: compute from existing data instead of duplicating it.
-
-Recommended mapping:
-- `useState` for local state.
-- `Zustand` or context for global UI state.
-- `TanStack Query` for server state.
-- Avoid context for high-frequency server data when query caching is the better fit.
-
-## Part 3: Composition and Contracts
-
-A component contract should define what it accepts, what it renders, and what events it emits.
-
-```javascript
-interface ButtonProps {
-  variant?: 'primary' | 'secondary' | 'danger';
-  size?: 'small' | 'medium' | 'large';
-  disabled?: boolean;
-  loading?: boolean;
-  onClick: () => void;
-  children: React.ReactNode;
-}
-```
-
-Keep public component APIs stable. If the component grows many optional props, split it into smaller feature-specific components instead of adding more flags.
-
-## Part 4: Anti-Patterns
-
-- Prop drilling across many levels.
-- Global context for everything.
-- Mixing network calls into presentational views.
-- Repeating derived values in both state and render.
-- Reaching into another feature's internals instead of using the feature public API.
-
-## Part 5: Design System Integration
-
-Design tokens should drive spacing, color, and sizing. Avoid one-off values unless the design system explicitly allows them.
-
-```javascript
-const buttonStyles = {
-  primary: 'bg-primary text-on-primary',
-  secondary: 'bg-surface text-primary',
-  danger: 'bg-danger text-on-danger'
-};
-```
-
-## Review Checklist
-
-- [ ] Smart and dumb layers are separated.
-- [ ] State ownership is minimal and deliberate.
-- [ ] Server state uses a cache-aware tool.
-- [ ] Component contracts are explicit and stable.
-- [ ] Feature boundaries are respected.
-- [ ] Design tokens are used consistently.
-- [ ] Prop drilling does not replace composition or shared state.
+# Component Architecture and State Management
+
+**Tier:** EXPERT | **Source:** awesome-copilot (smart/dumb) + minimax (design systems) + antigravity (React patterns)
+
+## Purpose
+
+UI architecture decides how state, behavior, and presentation are split. Good structure reduces re-render churn, keeps component boundaries stable, and makes features easier to test.
+
+## Part 1: Smart and Dumb Separation
+
+A smart component owns data flow, side effects, and orchestration. A dumb component renders input and emits events.
+
+```javascript
+function PaymentFormContainer() {
+  const [amount, setAmount] = useState('');
+  const [status, setStatus] = useState('idle');
+  const [errorMessage, setErrorMessage] = useState(null);
+
+  const handleSubmit = async (submittedAmount) => {
+    setStatus('loading');
+    try {
+      const response = await fetch('/api/payments', {
+        method: 'POST',
+        body: JSON.stringify({ amount: submittedAmount })
+      });
+
+      if (!response.ok) {
+        throw new Error('Payment request failed');
+      }
+
+      setStatus('success');
+    } catch (caughtError) {
+      setErrorMessage(caughtError.message);
+      setStatus('error');
+    }
+  };
+
+  return (
+    <PaymentFormView
+      amount={amount}
+      isLoading={status === 'loading'}
+      errorMessage={errorMessage}
+      onAmountChange={setAmount}
+      onSubmit={handleSubmit}
+    />
+  );
+}
+```
+
+```javascript
+function PaymentFormView({ amount, isLoading, errorMessage, onAmountChange, onSubmit }) {
+  return (
+    <form onSubmit={(event) => { event.preventDefault(); onSubmit(amount); }}>
+      <input
+        value={amount}
+        onChange={(event) => onAmountChange(event.target.value)}
+        disabled={isLoading}
+      />
+      <button disabled={isLoading}>
+        {isLoading ? 'Processing' : 'Pay'}
+      </button>
+      {errorMessage ? <p>{errorMessage}</p> : null}
+    </form>
+  );
+}
+```
+
+## Part 2: State Ownership Rules
+
+Use the smallest useful state scope.
+
+- Local component state: form fields, toggles, ephemeral UI state.
+- Shared UI state: theme, sidebar state, modal visibility.
+- Server state: remote data, caching, invalidation, refetching.
+- Derived state: compute from existing data instead of duplicating it.
+
+Recommended mapping:
+- `useState` for local state.
+- `Zustand` or context for global UI state.
+- `TanStack Query` for server state.
+- Avoid context for high-frequency server data when query caching is the better fit.
+
+## Part 3: Composition and Contracts
+
+A component contract should define what it accepts, what it renders, and what events it emits.
+
+```javascript
+interface ButtonProps {
+  variant?: 'primary' | 'secondary' | 'danger';
+  size?: 'small' | 'medium' | 'large';
+  disabled?: boolean;
+  loading?: boolean;
+  onClick: () => void;
+  children: React.ReactNode;
+}
+```
+
+Keep public component APIs stable. If the component grows many optional props, split it into smaller feature-specific components instead of adding more flags.
+
+## Part 4: Anti-Patterns
+
+- Prop drilling across many levels.
+- Global context for everything.
+- Mixing network calls into presentational views.
+- Repeating derived values in both state and render.
+- Reaching into another feature's internals instead of using the feature public API.
+
+## Part 5: Design System Integration
+
+Design tokens should drive spacing, color, and sizing. Avoid one-off values unless the design system explicitly allows them.
+
+```javascript
+const buttonStyles = {
+  primary: 'bg-primary text-on-primary',
+  secondary: 'bg-surface text-primary',
+  danger: 'bg-danger text-on-danger'
+};
+```
+
+## Review Checklist
+
+- [ ] Smart and dumb layers are separated.
+- [ ] State ownership is minimal and deliberate.
+- [ ] Server state uses a cache-aware tool.
+- [ ] Component contracts are explicit and stable.
+- [ ] Feature boundaries are respected.
+- [ ] Design tokens are used consistently.
+- [ ] Prop drilling does not replace composition or shared state.

package/.agent-context/skills/frontend.md

@@ -1,30 +1,30 @@
-# Frontend Skill Pack
-
-Default tier: `advance`
-
-## Purpose
-Deliver frontend experiences that are visually intentional, accessible, and efficient.
-
-## In Scope
-- UI architecture and component composition
-- Responsive layouts and breakpoints
-- Motion, animation, and interaction polish
-- Accessibility and keyboard flows
-- Conversion clarity and onboarding flow
-
-## Must-Have Checks
-- Feature-driven folder structure
-- Smart and dumb component separation
-- Server state and client state separation
-- Reduced-motion fallback
-- Accessibility baseline pass
-- Responsive behavior verified on mobile and desktop
-
-## Evidence
-- Usability audit result
-- Visual regression output
-- Accessibility checklist result
-- Release notes for motion and interaction changes
-
-## Fallback
+# Frontend Skill Pack
+
+Default tier: `advance`
+
+## Purpose
+Deliver frontend experiences that are visually intentional, accessible, and efficient.
+
+## In Scope
+- UI architecture and component composition
+- Responsive layouts and breakpoints
+- Motion, animation, and interaction polish
+- Accessibility and keyboard flows
+- Conversion clarity and onboarding flow
+
+## Must-Have Checks
+- Feature-driven folder structure
+- Smart and dumb component separation
+- Server state and client state separation
+- Reduced-motion fallback
+- Accessibility baseline pass
+- Responsive behavior verified on mobile and desktop
+
+## Evidence
+- Usability audit result
+- Visual regression output
+- Accessibility checklist result
+- Release notes for motion and interaction changes
+
+## Fallback
 - If a feature cannot meet the advance tier, ship standard mode only as a temporary compatibility path.

package/.agent-context/skills/fullstack/README.md

@@ -1,19 +1,19 @@
-# Fullstack Engineering Skills
-
-Default tier: `advance`
-
-This domain connects frontend and backend implementation into a single feature-delivery workflow. The guidance combines architecture patterns from awesome-copilot, operational checklists from MiniMax, and practical delivery patterns from antigravity.
-
-## Topics
-- [Feature Slicing](feature-slicing.md) - Organize UI, service, repository, and tests around one business capability
-- [Contracts](contracts.md) - Keep API schemas, DTOs, and frontend types synchronized
-- [End-to-End](end-to-end.md) - Release readiness by verified user journeys and operational gates
-
-## Operating Model
-- Use `advance` for normal feature development.
-- Escalate to `expert` when a feature crosses multiple bounded contexts or service boundaries.
-
-## Above-Line Additions
-- Contract drift detection in CI before merge.
-- Backward-compatibility checks for API changes.
+# Fullstack Engineering Skills
+
+Default tier: `advance`
+
+This domain connects frontend and backend implementation into a single feature-delivery workflow. The guidance combines architecture patterns from awesome-copilot, operational checklists from MiniMax, and practical delivery patterns from antigravity.
+
+## Topics
+- [Feature Slicing](feature-slicing.md) - Organize UI, service, repository, and tests around one business capability
+- [Contracts](contracts.md) - Keep API schemas, DTOs, and frontend types synchronized
+- [End-to-End](end-to-end.md) - Release readiness by verified user journeys and operational gates
+
+## Operating Model
+- Use `advance` for normal feature development.
+- Escalate to `expert` when a feature crosses multiple bounded contexts or service boundaries.
+
+## Above-Line Additions
+- Contract drift detection in CI before merge.
+- Backward-compatibility checks for API changes.
 - Release evidence bundle for end-to-end readiness.

package/.agent-context/skills/fullstack/contracts.md

@@ -1,53 +1,53 @@
-# Contracts
-
-Tier: EXPERT
-
-Contracts keep frontend expectations and backend behavior aligned through explicit schemas. A contract is not documentation only; it is an executable guardrail.
-
-## Contract Sources
-
-- API specification: OpenAPI 3.1 for HTTP boundaries.
-- Runtime validation: Zod/Pydantic at service edges.
-- Type generation: frontend types generated from server contract.
-
-## Required Pipeline
-
-1. Define or update schema in contract source.
-2. Regenerate consumer types.
-3. Run contract tests against provider and consumer.
-4. Fail CI if drift is detected.
-
-## Drift Prevention
-
-Common drift scenarios:
-- Backend renames field but frontend still expects old key.
-- Enum expands or changes values without consumer handling.
-- Response shape changes silently in minor release.
-
-Control strategy:
-- Pin contract artifact version.
-- Require schema diff check in pull request.
-- Block merge on unreviewed breaking changes.
-
-## Breaking Change Policy
-
-- Additive changes: allowed in minor version if backward-compatible.
-- Behavioral changes: require release note and migration note.
-- Breaking schema changes: major version bump with compatibility plan.
-
-## Example Workflow
-
-```text
-contracts/openapi.yaml updated
--> generate frontend types
--> run provider contract tests
--> run consumer compatibility tests
--> publish artifact only if all checks pass
-```
-
-## Review Checklist
-
-- [ ] Contract source is versioned and reviewed.
-- [ ] Provider and consumer tests both pass.
-- [ ] Breaking changes are tagged and documented.
+# Contracts
+
+Tier: EXPERT
+
+Contracts keep frontend expectations and backend behavior aligned through explicit schemas. A contract is not documentation only; it is an executable guardrail.
+
+## Contract Sources
+
+- API specification: OpenAPI 3.1 for HTTP boundaries.
+- Runtime validation: Zod/Pydantic at service edges.
+- Type generation: frontend types generated from server contract.
+
+## Required Pipeline
+
+1. Define or update schema in contract source.
+2. Regenerate consumer types.
+3. Run contract tests against provider and consumer.
+4. Fail CI if drift is detected.
+
+## Drift Prevention
+
+Common drift scenarios:
+- Backend renames field but frontend still expects old key.
+- Enum expands or changes values without consumer handling.
+- Response shape changes silently in minor release.
+
+Control strategy:
+- Pin contract artifact version.
+- Require schema diff check in pull request.
+- Block merge on unreviewed breaking changes.
+
+## Breaking Change Policy
+
+- Additive changes: allowed in minor version if backward-compatible.
+- Behavioral changes: require release note and migration note.
+- Breaking schema changes: major version bump with compatibility plan.
+
+## Example Workflow
+
+```text
+contracts/openapi.yaml updated
+-> generate frontend types
+-> run provider contract tests
+-> run consumer compatibility tests
+-> publish artifact only if all checks pass
+```
+
+## Review Checklist
+
+- [ ] Contract source is versioned and reviewed.
+- [ ] Provider and consumer tests both pass.
+- [ ] Breaking changes are tagged and documented.
 - [ ] Migration path is included before release.

package/.agent-context/skills/fullstack/end-to-end.md

@@ -1,42 +1,42 @@
-# End-to-End
-
-Tier: ADVANCE
-
-End-to-end validation is the final quality gate that confirms critical user behavior across UI, API, persistence, and integrations.
-
-## Critical Paths First
-
-Always cover:
-- Authentication and session lifecycle.
-- Primary revenue path (example: checkout, payment, order completion).
-- Error recovery paths (timeouts, retries, invalid input).
-- Role-based authorization boundaries.
-
-## Test Strategy
-
-- Unit tests: fast local confidence.
-- Integration tests: service and repository behavior.
-- End-to-end tests: user-visible workflows in realistic environment.
-
-End-to-end tests should be selective and high signal. Avoid using them to test every internal branch.
-
-## Release Evidence Bundle
-
-For each release candidate, publish:
-- End-to-end test report for critical journeys.
-- Contract validation report.
-- Benchmark delta report for performance-sensitive flows.
-- Known risk summary and mitigation owner.
-
-## Failure Policy
-
-- Block release on failed critical journey tests.
-- Block release when test environment is inconsistent with target runtime.
-- Allow non-critical failures only with explicit risk acceptance and owner.
-
-## Review Checklist
-
-- [ ] Critical user journeys are covered.
-- [ ] End-to-end tests run in CI on release candidate.
-- [ ] Reports are archived as release artifacts.
+# End-to-End
+
+Tier: ADVANCE
+
+End-to-end validation is the final quality gate that confirms critical user behavior across UI, API, persistence, and integrations.
+
+## Critical Paths First
+
+Always cover:
+- Authentication and session lifecycle.
+- Primary revenue path (example: checkout, payment, order completion).
+- Error recovery paths (timeouts, retries, invalid input).
+- Role-based authorization boundaries.
+
+## Test Strategy
+
+- Unit tests: fast local confidence.
+- Integration tests: service and repository behavior.
+- End-to-end tests: user-visible workflows in realistic environment.
+
+End-to-end tests should be selective and high signal. Avoid using them to test every internal branch.
+
+## Release Evidence Bundle
+
+For each release candidate, publish:
+- End-to-end test report for critical journeys.
+- Contract validation report.
+- Benchmark delta report for performance-sensitive flows.
+- Known risk summary and mitigation owner.
+
+## Failure Policy
+
+- Block release on failed critical journey tests.
+- Block release when test environment is inconsistent with target runtime.
+- Allow non-critical failures only with explicit risk acceptance and owner.
+
+## Review Checklist
+
+- [ ] Critical user journeys are covered.
+- [ ] End-to-end tests run in CI on release candidate.
+- [ ] Reports are archived as release artifacts.
 - [ ] Failures are triaged with owner and deadline.

package/.agent-context/skills/fullstack/feature-slicing.md

@@ -1,65 +1,65 @@
-# Feature Slicing
-
-Tier: ADVANCE
-
-Feature slicing organizes implementation around business capabilities instead of technical file types. A single feature owns its UI, service orchestration, persistence adapters, and tests.
-
-## Why It Matters
-
-- Improves ownership: one team can ship and maintain a feature end to end.
-- Reduces coupling: changes stay local to one capability.
-- Speeds delivery: less coordination across unrelated folders.
-
-## Recommended Layout
-
-```text
-src/
-	features/
-		checkout/
-			ui/
-			service/
-			repository/
-			contracts/
-			tests/
-			index.ts
-		orders/
-			ui/
-			service/
-			repository/
-			contracts/
-			tests/
-			index.ts
-```
-
-## Module Boundary Rules
-
-- Expose only through `index.ts` as the feature public API.
-- Do not import private files across feature folders.
-- Keep shared utilities in a neutral shared module; avoid feature-to-feature deep imports.
-
-## Anti-Patterns
-
-Bad:
-- `src/components`, `src/services`, `src/repositories` global buckets for all features.
-- Shared folder becoming a dumping ground for feature-specific code.
-- One feature mutating another feature's database entities directly.
-
-Good:
-- Feature package exposes explicit use-cases and UI entrypoints.
-- Cross-feature communication uses contracts and events.
-- Shared module limited to stateless primitives and infrastructure adapters.
-
-## Integration Workflow
-
-1. Define capability and boundary (example: checkout).
-2. Define public API for the feature module.
-3. Implement UI and service logic inside the feature.
-4. Add repository and contract definitions.
-5. Add unit/integration/end-to-end tests within the feature.
-
-## Review Checklist
-
-- [ ] Feature can be understood without reading unrelated modules.
-- [ ] No deep import across feature boundaries.
-- [ ] Public API is explicit and stable.
+# Feature Slicing
+
+Tier: ADVANCE
+
+Feature slicing organizes implementation around business capabilities instead of technical file types. A single feature owns its UI, service orchestration, persistence adapters, and tests.
+
+## Why It Matters
+
+- Improves ownership: one team can ship and maintain a feature end to end.
+- Reduces coupling: changes stay local to one capability.
+- Speeds delivery: less coordination across unrelated folders.
+
+## Recommended Layout
+
+```text
+src/
+	features/
+		checkout/
+			ui/
+			service/
+			repository/
+			contracts/
+			tests/
+			index.ts
+		orders/
+			ui/
+			service/
+			repository/
+			contracts/
+			tests/
+			index.ts
+```
+
+## Module Boundary Rules
+
+- Expose only through `index.ts` as the feature public API.
+- Do not import private files across feature folders.
+- Keep shared utilities in a neutral shared module; avoid feature-to-feature deep imports.
+
+## Anti-Patterns
+
+Bad:
+- `src/components`, `src/services`, `src/repositories` global buckets for all features.
+- Shared folder becoming a dumping ground for feature-specific code.
+- One feature mutating another feature's database entities directly.
+
+Good:
+- Feature package exposes explicit use-cases and UI entrypoints.
+- Cross-feature communication uses contracts and events.
+- Shared module limited to stateless primitives and infrastructure adapters.
+
+## Integration Workflow
+
+1. Define capability and boundary (example: checkout).
+2. Define public API for the feature module.
+3. Implement UI and service logic inside the feature.
+4. Add repository and contract definitions.
+5. Add unit/integration/end-to-end tests within the feature.
+
+## Review Checklist
+
+- [ ] Feature can be understood without reading unrelated modules.
+- [ ] No deep import across feature boundaries.
+- [ ] Public API is explicit and stable.
 - [ ] Tests live with the feature and cover core behavior.