@ryuenn3123/agentic-senior-core 2.0.5 → 2.0.7

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

@@ -1,19 +1,27 @@
-# 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.
+# 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
+- [Release Coordination](release-coordination.md) - Multi-service rollout ordering, rollback thresholds, and evidence handoff
+
+## 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.
+
+## Usage Example
+
+```bash
+agentic-senior-core init --preset fullstack-product
+node ./scripts/quality-trend-report.mjs
+```

package/.agent-context/skills/fullstack/compatibility-manifest.json

@@ -1,8 +1,8 @@
-{
-  "schemaVersion": "compatibility-manifest-v1",
-  "artifactType": "skill-domain",
-  "domain": "fullstack",
-  "ides": ["cursor", "windsurf", "copilot", "gemini", "claude", "codex", "cline"],
-  "nodeMin": "18",
-  "platforms": ["windows", "linux", "macos"]
-}
+{
+  "schemaVersion": "compatibility-manifest-v1",
+  "artifactType": "skill-domain",
+  "domain": "fullstack",
+  "ides": ["cursor", "windsurf", "copilot", "gemini", "claude", "codex", "cline"],
+  "nodeMin": "18",
+  "platforms": ["windows", "linux", "macos"]
+}

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.

package/.agent-context/skills/fullstack/package.json

@@ -0,0 +1,5 @@
+{
+  "name": "@agentic-skills/fullstack",
+  "version": "1.0.0",
+  "author": "agentic"
+}

package/.agent-context/skills/fullstack/release-coordination.md

@@ -0,0 +1,51 @@
+# Release Coordination
+
+Tier: EXPERT
+
+Release coordination in fullstack systems aligns UI rollout, API compatibility, data migration timing, and rollback readiness across teams.
+
+## Coordination Matrix
+
+Define a shared release matrix before merge:
+
+- Frontend deployment window and feature-flag activation point.
+- Backend deployment order and compatibility grace period.
+- Data migration execution and rollback scope.
+- Observability checks required for release acceptance.
+
+## Rollout Sequencing
+
+Use an order that preserves backward compatibility:
+
+1. Deploy backend changes in compatibility mode.
+2. Verify contract and benchmark gates.
+3. Deploy frontend consuming new contract.
+4. Enable feature flags progressively.
+5. Remove compatibility shim in a later release.
+
+## Blocker Handling
+
+Track blocker categories with explicit owners:
+
+- Contract mismatch blockers.
+- Performance regression blockers.
+- Accessibility or conversion regression blockers.
+- Migration and rollback uncertainty blockers.
+
+A release can proceed only when blocker list is empty or risk acceptance is approved and documented.
+
+## Evidence Handoff
+
+Release evidence bundle should include:
+
+- End-to-end report for critical journeys.
+- Contract validation and diff summary.
+- Benchmark and quality-trend snapshot.
+- Rollback drill or recovery playbook reference.
+
+## Review Checklist
+
+- [ ] Rollout sequence keeps consumer/provider compatibility.
+- [ ] Blockers have owner and due date before release review.
+- [ ] Feature flags are mapped to rollback strategy.
+- [ ] Evidence bundle is attached to release decision.

package/.agent-context/skills/fullstack/tests/.gitkeep

@@ -0,0 +1 @@
+# Fullstack skill test fixtures placeholder

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

@@ -1,27 +1,30 @@
-# Fullstack Skill Pack
-
-Default tier: `advance`
-
-## Purpose
-Coordinate frontend and backend delivery as a single product system.
-
-## In Scope
-- Feature slicing across UI and API boundaries
-- Shared validation contracts
-- End-to-end flows and release readiness
-- Performance, accessibility, and observability together
-
-## Must-Have Checks
-- Single feature directory with clear public API
-- Frontend and backend contracts aligned
-- End-to-end test coverage for critical paths
-- Release notes explain UX and API impact together
-
-## Evidence
-- Feature parity checklist
-- End-to-end test report
-- Contract validation output
-- Release artifact bundle
-
-## Fallback
+# Fullstack Skill Pack
+
+Default tier: `advance`
+
+## Purpose
+Coordinate frontend and backend delivery as a single product system.
+
+## In Scope
+- Feature slicing across UI and API boundaries
+- Shared validation contracts
+- End-to-end flows and release readiness
+- Performance, accessibility, and observability together
+- Release coordination and rollback preparation across services
+
+## Must-Have Checks
+- Single feature directory with clear public API
+- Frontend and backend contracts aligned
+- End-to-end test coverage for critical paths
+- Release notes explain UX and API impact together
+- Cross-service rollout order and rollback trigger criteria are documented
+
+## Evidence
+- Feature parity checklist
+- End-to-end test report
+- Contract validation output
+- Release artifact bundle
+- Rollout/rollback decision log for multi-service features
+
+## Fallback
 - Split delivery only when the feature boundary is explicit and the evidence bundle is still complete.