@ryuenn3123/agentic-senior-core 2.0.4 → 2.0.7
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.agent-context/blueprints/mobile-app.md +82 -12
- package/.agent-context/skills/cli/README.md +6 -0
- package/.agent-context/skills/cli/safety-telemetry.md +39 -0
- package/.agent-context/skills/cli.md +3 -0
- package/.agent-context/skills/distribution/.evidence/compatibility-manifest.json +9 -0
- package/.agent-context/skills/distribution/.evidence/sbom-excerpt.json +6 -0
- package/.agent-context/skills/distribution/.evidence/test-report.json +8 -0
- package/.agent-context/skills/distribution/CHANGELOG.md +7 -0
- package/.agent-context/skills/distribution/README.md +9 -1
- package/.agent-context/skills/distribution/package.json +5 -0
- package/.agent-context/skills/distribution/provenance-attestation.md +47 -0
- package/.agent-context/skills/distribution/tests/.gitkeep +1 -0
- package/.agent-context/skills/distribution.md +3 -0
- package/.agent-context/skills/frontend/.evidence/compatibility-manifest.json +9 -0
- package/.agent-context/skills/frontend/.evidence/sbom-excerpt.json +6 -0
- package/.agent-context/skills/frontend/.evidence/test-report.json +8 -0
- package/.agent-context/skills/frontend/CHANGELOG.md +7 -0
- package/.agent-context/skills/frontend/README.md +14 -1
- package/.agent-context/skills/frontend/conversion-clarity.md +51 -0
- package/.agent-context/skills/frontend/package.json +5 -0
- package/.agent-context/skills/frontend/responsive-delivery.md +41 -0
- package/.agent-context/skills/frontend/tests/.gitkeep +1 -0
- package/.agent-context/skills/frontend.md +6 -0
- package/.agent-context/skills/fullstack/.evidence/compatibility-manifest.json +9 -0
- package/.agent-context/skills/fullstack/.evidence/sbom-excerpt.json +6 -0
- package/.agent-context/skills/fullstack/.evidence/test-report.json +8 -0
- package/.agent-context/skills/fullstack/CHANGELOG.md +7 -0
- package/.agent-context/skills/fullstack/README.md +9 -1
- package/.agent-context/skills/fullstack/package.json +5 -0
- package/.agent-context/skills/fullstack/release-coordination.md +51 -0
- package/.agent-context/skills/fullstack/tests/.gitkeep +1 -0
- package/.agent-context/skills/fullstack.md +3 -0
- package/.agent-context/skills/review-quality/.evidence/compatibility-manifest.json +9 -0
- package/.agent-context/skills/review-quality/.evidence/sbom-excerpt.json +6 -0
- package/.agent-context/skills/review-quality/.evidence/test-report.json +8 -0
- package/.agent-context/skills/review-quality/CHANGELOG.md +7 -0
- package/.agent-context/skills/review-quality/README.md +9 -1
- package/.agent-context/skills/review-quality/package.json +5 -0
- package/.agent-context/skills/review-quality/release-decision.md +49 -0
- package/.agent-context/skills/review-quality/tests/.gitkeep +1 -0
- package/.agent-context/skills/review-quality.md +3 -0
- package/.agent-context/state/quality-trend-report.json +89 -0
- package/.agent-context/state/weekly-governance-report.json +126 -0
- package/.cursorrules +1 -1
- package/.gemini/instructions.md +15 -91
- package/.github/copilot-instructions.md +15 -160
- package/.github/workflows/governance-weekly-report.yml +43 -0
- package/.windsurfrules +1 -1
- package/AGENTS.md +21 -174
- package/README.md +15 -0
- package/lib/cli/constants.mjs +35 -0
- package/lib/cli/utils.mjs +4 -1
- package/package.json +3 -1
- package/scripts/governance-weekly-report.mjs +293 -0
- package/scripts/quality-trend-report.mjs +289 -0
- package/scripts/release-gate.mjs +57 -0
- package/scripts/validate.mjs +85 -22
|
@@ -1,21 +1,91 @@
|
|
|
1
1
|
# Mobile App Blueprint
|
|
2
2
|
|
|
3
|
-
This blueprint defines
|
|
3
|
+
This blueprint defines a production starter for mobile products that need strict separation between UI flow, device integration, offline behavior, and backend contracts.
|
|
4
4
|
|
|
5
|
-
##
|
|
5
|
+
## Reference Architecture
|
|
6
6
|
|
|
7
|
-
|
|
8
|
-
- Service: orchestration, screen-level state, validation, and user-facing workflows.
|
|
9
|
-
- Repository: remote API clients, local storage adapters, and persistence abstractions.
|
|
7
|
+
Use a three-layer mobile module boundary:
|
|
10
8
|
|
|
11
|
-
|
|
9
|
+
- Transport layer: navigation routes, deep links, push notification handlers, platform lifecycle hooks.
|
|
10
|
+
- Service layer: screen orchestration, input validation, business workflows, permission policy decisions.
|
|
11
|
+
- Repository layer: API clients, local persistence, cache synchronization, device adapter wrappers.
|
|
12
12
|
|
|
13
|
-
|
|
14
|
-
|
|
15
|
-
|
|
16
|
-
|
|
13
|
+
## Suggested Structure
|
|
14
|
+
|
|
15
|
+
```text
|
|
16
|
+
mobile/
|
|
17
|
+
app/
|
|
18
|
+
navigation/
|
|
19
|
+
screens/
|
|
20
|
+
feature-flags/
|
|
21
|
+
features/
|
|
22
|
+
checkout/
|
|
23
|
+
ui/
|
|
24
|
+
service/
|
|
25
|
+
repository/
|
|
26
|
+
contracts/
|
|
27
|
+
tests/
|
|
28
|
+
index.ts
|
|
29
|
+
account/
|
|
30
|
+
ui/
|
|
31
|
+
service/
|
|
32
|
+
repository/
|
|
33
|
+
contracts/
|
|
34
|
+
tests/
|
|
35
|
+
index.ts
|
|
36
|
+
shared/
|
|
37
|
+
design-tokens/
|
|
38
|
+
telemetry/
|
|
39
|
+
error-boundaries/
|
|
40
|
+
accessibility/
|
|
41
|
+
```
|
|
42
|
+
|
|
43
|
+
## State and Data Rules
|
|
44
|
+
|
|
45
|
+
- Keep transient UI state local to the screen component.
|
|
46
|
+
- Keep feature workflow state in service-level orchestrators.
|
|
47
|
+
- Keep remote and local synchronization logic in repository adapters.
|
|
48
|
+
- Enforce idempotent retry semantics for background sync and push-triggered refresh.
|
|
49
|
+
|
|
50
|
+
## Device and Platform Boundaries
|
|
51
|
+
|
|
52
|
+
- Wrap native modules behind explicit interfaces.
|
|
53
|
+
- Keep iOS/Android-specific behavior in adapter files, not in feature UI components.
|
|
54
|
+
- Centralize permission checks for camera, location, notifications, and storage.
|
|
55
|
+
- Define fallback behavior for denied permissions before QA sign-off.
|
|
56
|
+
|
|
57
|
+
## Offline and Failure Handling
|
|
58
|
+
|
|
59
|
+
- Define offline-first behavior per feature (read-only, queued writes, or blocked operations).
|
|
60
|
+
- Persist pending mutations with retry metadata.
|
|
61
|
+
- Show explicit user-facing recovery actions for network and permission failures.
|
|
62
|
+
- Log mobile crash context with feature name, operation, and user impact summary.
|
|
63
|
+
|
|
64
|
+
## Testing Baseline
|
|
65
|
+
|
|
66
|
+
- Unit tests: service decisions, validation, and adapter boundary behavior.
|
|
67
|
+
- Integration tests: repository sync logic with mocked device/network behavior.
|
|
68
|
+
- End-to-end tests: critical journeys (login, primary conversion flow, error recovery path).
|
|
69
|
+
- Accessibility checks: screen reader labels, focus order, and reduced-motion behavior.
|
|
70
|
+
|
|
71
|
+
## Release Governance
|
|
72
|
+
|
|
73
|
+
Before shipping each mobile release candidate:
|
|
74
|
+
|
|
75
|
+
- Verify signing and packaging pipeline integrity.
|
|
76
|
+
- Verify crash-free session and startup stability thresholds.
|
|
77
|
+
- Verify telemetry/analytics payload schema compatibility.
|
|
78
|
+
- Verify rollback strategy for binary release and remote config toggles.
|
|
17
79
|
|
|
18
80
|
## Recommended Stack Pairings
|
|
19
81
|
|
|
20
|
-
- React Native for teams that want JavaScript or TypeScript alignment.
|
|
21
|
-
- Flutter for teams that want
|
|
82
|
+
- React Native for teams that want JavaScript or TypeScript alignment and shared web hiring pool.
|
|
83
|
+
- Flutter for teams that want consistent rendering across platforms and widget-driven architecture.
|
|
84
|
+
|
|
85
|
+
## Blueprint Checklist
|
|
86
|
+
|
|
87
|
+
- [ ] Feature boundaries are modular and explicit.
|
|
88
|
+
- [ ] Device adapters are isolated from UI rendering code.
|
|
89
|
+
- [ ] Offline and permission failure behavior is documented.
|
|
90
|
+
- [ ] Critical mobile journeys are covered by automated tests.
|
|
91
|
+
- [ ] Release package and telemetry gates are enforced before ship.
|
|
@@ -8,6 +8,7 @@ This domain covers command design, safe mutation workflows, and machine-readable
|
|
|
8
8
|
- [Init Flow](init.md) - Deterministic project initialization with explicit write plans
|
|
9
9
|
- [Upgrade Flow](upgrade.md) - Safe upgrades with dry-run, rollback, and compatibility checks
|
|
10
10
|
- [Machine-Readable Output](output.md) - Stable JSON output and deterministic exit semantics
|
|
11
|
+
- [Safety and Telemetry](safety-telemetry.md) - Operational signal capture and release-facing CLI governance summaries
|
|
11
12
|
|
|
12
13
|
## Operating Model
|
|
13
14
|
- Use `advance` for normal command work.
|
|
@@ -40,6 +41,11 @@ Use presets when you want fewer choices at the start:
|
|
|
40
41
|
- `mobile-react-native` - React Native + mobile app + balanced profile.
|
|
41
42
|
- `mobile-flutter` - Flutter + mobile app + balanced profile.
|
|
42
43
|
- `observability-platform` - Go + observability + strict profile.
|
|
44
|
+
- `typescript-nestjs-service` - TypeScript + NestJS module blueprint + balanced profile.
|
|
45
|
+
- `java-enterprise-api` - Java + Spring Boot API + strict profile.
|
|
46
|
+
- `dotnet-enterprise-api` - C# + ASP.NET API + strict profile.
|
|
47
|
+
- `php-laravel-api` - PHP + Laravel API + balanced profile.
|
|
48
|
+
- `kubernetes-platform` - Go + Kubernetes manifests + strict profile.
|
|
43
49
|
|
|
44
50
|
Example:
|
|
45
51
|
|
|
@@ -0,0 +1,39 @@
|
|
|
1
|
+
# Safety and Telemetry
|
|
2
|
+
|
|
3
|
+
Tier: ADVANCE
|
|
4
|
+
|
|
5
|
+
CLI safety telemetry captures operational signals that help maintainers detect drift, reduce onboarding failures, and enforce release quality.
|
|
6
|
+
|
|
7
|
+
## Signal Categories
|
|
8
|
+
|
|
9
|
+
Capture and review machine-readable CLI signals:
|
|
10
|
+
|
|
11
|
+
- Validation and release-gate status.
|
|
12
|
+
- Preflight failure categories.
|
|
13
|
+
- Rollback trigger frequency.
|
|
14
|
+
- Preset usage distribution across onboarding sessions.
|
|
15
|
+
|
|
16
|
+
## Output Contract
|
|
17
|
+
|
|
18
|
+
Telemetry reports should remain automation-friendly:
|
|
19
|
+
|
|
20
|
+
- Stable JSON shape.
|
|
21
|
+
- ISO timestamps.
|
|
22
|
+
- Explicit status fields.
|
|
23
|
+
- Actionable blocker summary.
|
|
24
|
+
|
|
25
|
+
Human-facing logs can remain concise, but automation payloads should preserve full diagnostic details.
|
|
26
|
+
|
|
27
|
+
## Governance Use Cases
|
|
28
|
+
|
|
29
|
+
- Weekly maintainership report generation.
|
|
30
|
+
- Detecting repeated onboarding failures caused by conflicting local files.
|
|
31
|
+
- Tracking whether preset expansion improves adoption.
|
|
32
|
+
- Confirming rollback operations remain low-frequency and controlled.
|
|
33
|
+
|
|
34
|
+
## Review Checklist
|
|
35
|
+
|
|
36
|
+
- [ ] Safety signals are emitted in machine-readable format.
|
|
37
|
+
- [ ] Preset and failure telemetry are captured consistently.
|
|
38
|
+
- [ ] Operational reports include blocker summaries.
|
|
39
|
+
- [ ] Telemetry output is suitable for CI artifact upload.
|
|
@@ -11,6 +11,7 @@ Create smart command-line workflows that guide users efficiently and safely.
|
|
|
11
11
|
- Machine-readable output for automation
|
|
12
12
|
- Validation and self-healing hooks
|
|
13
13
|
- Cross-platform shell behavior
|
|
14
|
+
- Preset ergonomics and operational telemetry outputs
|
|
14
15
|
|
|
15
16
|
## Must-Have Checks
|
|
16
17
|
- Explicit command help and examples
|
|
@@ -18,12 +19,14 @@ Create smart command-line workflows that guide users efficiently and safely.
|
|
|
18
19
|
- Safe destructive-action guards
|
|
19
20
|
- Validation before mutation
|
|
20
21
|
- Exit codes reflect success and failure clearly
|
|
22
|
+
- Preset catalog remains discoverable and tested in smoke tests
|
|
21
23
|
|
|
22
24
|
## Evidence
|
|
23
25
|
- CLI smoke tests
|
|
24
26
|
- Machine-readable report output
|
|
25
27
|
- Upgrade dry-run output
|
|
26
28
|
- Cross-platform execution notes
|
|
29
|
+
- Weekly governance report references CLI trust tier and release posture
|
|
27
30
|
|
|
28
31
|
## Fallback
|
|
29
32
|
- Standard mode can remain available for compatibility, but advance is the default user experience.
|
|
@@ -0,0 +1,9 @@
|
|
|
1
|
+
{
|
|
2
|
+
"schemaVersion": "compatibility-manifest-v1",
|
|
3
|
+
"artifactType": "skill-domain-evidence",
|
|
4
|
+
"domain": "distribution",
|
|
5
|
+
"ides": ["cursor", "windsurf", "copilot", "gemini", "claude", "codex", "cline"],
|
|
6
|
+
"nodeMin": "18",
|
|
7
|
+
"platforms": ["windows", "linux", "macos"],
|
|
8
|
+
"validatedAt": "2026-04-11T12:00:00Z"
|
|
9
|
+
}
|
|
@@ -8,6 +8,7 @@ This domain governs release packaging, compatibility policy, and rollback readin
|
|
|
8
8
|
- [Publish Hygiene](publish.md) - Package integrity, provenance, and release evidence
|
|
9
9
|
- [Rollback](rollback.md) - Recovery-first release operations
|
|
10
10
|
- [Compatibility](compatibility.md) - Runtime/tooling support policy and guardrails
|
|
11
|
+
- [Provenance Attestation](provenance-attestation.md) - SBOM linkage, artifact identity, and maintainership traceability
|
|
11
12
|
|
|
12
13
|
## Operating Model
|
|
13
14
|
- Use `expert` as the default distribution tier.
|
|
@@ -16,4 +17,11 @@ This domain governs release packaging, compatibility policy, and rollback readin
|
|
|
16
17
|
## Above-Line Additions
|
|
17
18
|
- Release gates tied to benchmark and compatibility checks.
|
|
18
19
|
- Supply-chain artifacts (SBOM/provenance) as first-class outputs.
|
|
19
|
-
- Explicit rollback drills before critical releases.
|
|
20
|
+
- Explicit rollback drills before critical releases.
|
|
21
|
+
|
|
22
|
+
## Usage Example
|
|
23
|
+
|
|
24
|
+
```bash
|
|
25
|
+
npm run gate:release
|
|
26
|
+
npm run report:governance-weekly
|
|
27
|
+
```
|
|
@@ -0,0 +1,47 @@
|
|
|
1
|
+
# Provenance Attestation
|
|
2
|
+
|
|
3
|
+
Tier: EXPERT
|
|
4
|
+
|
|
5
|
+
Provenance attestation links shipped artifacts to source commits, policy gates, and maintainer intent so releases remain auditable.
|
|
6
|
+
|
|
7
|
+
## Attestation Requirements
|
|
8
|
+
|
|
9
|
+
Every release artifact should be traceable to:
|
|
10
|
+
|
|
11
|
+
- Source commit SHA.
|
|
12
|
+
- Versioned changelog entry.
|
|
13
|
+
- Gate evidence (release gate, benchmark, security checks).
|
|
14
|
+
- Maintainer identity and release timestamp.
|
|
15
|
+
|
|
16
|
+
## Artifact Chain
|
|
17
|
+
|
|
18
|
+
Maintain a simple provenance chain:
|
|
19
|
+
|
|
20
|
+
1. Build artifact from tagged commit.
|
|
21
|
+
2. Generate SBOM and integrity digest.
|
|
22
|
+
3. Attach gate output artifacts.
|
|
23
|
+
4. Publish with immutable version metadata.
|
|
24
|
+
|
|
25
|
+
If any step is missing, release should be blocked until evidence is complete.
|
|
26
|
+
|
|
27
|
+
## Tamper-Resistance Controls
|
|
28
|
+
|
|
29
|
+
- Avoid manual artifact replacement outside CI path.
|
|
30
|
+
- Keep checksums in release notes or signed metadata.
|
|
31
|
+
- Enforce immutable package versions after publish.
|
|
32
|
+
- Store audit artifacts with retention policy.
|
|
33
|
+
|
|
34
|
+
## Operational Review
|
|
35
|
+
|
|
36
|
+
At weekly cadence, review provenance quality:
|
|
37
|
+
|
|
38
|
+
- Are all recent releases traceable end to end?
|
|
39
|
+
- Were any gates bypassed or manually overridden?
|
|
40
|
+
- Are SBOM and compatibility manifests synchronized?
|
|
41
|
+
|
|
42
|
+
## Review Checklist
|
|
43
|
+
|
|
44
|
+
- [ ] Source commit and version metadata are linked.
|
|
45
|
+
- [ ] SBOM and checksum artifacts are attached.
|
|
46
|
+
- [ ] Gate evidence is complete and timestamped.
|
|
47
|
+
- [ ] No unsigned or out-of-band artifact replacement occurred.
|
|
@@ -0,0 +1 @@
|
|
|
1
|
+
# Distribution skill test fixtures placeholder
|
|
@@ -11,6 +11,7 @@ Protect package installation and release distribution with transactional safety.
|
|
|
11
11
|
- Compatibility checks
|
|
12
12
|
- Forbidden-file detection
|
|
13
13
|
- Publish hygiene and provenance
|
|
14
|
+
- Dependency audit evidence and attestations
|
|
14
15
|
|
|
15
16
|
## Must-Have Checks
|
|
16
17
|
- Preflight validation before installation or publish
|
|
@@ -18,12 +19,14 @@ Protect package installation and release distribution with transactional safety.
|
|
|
18
19
|
- Automatic rollback on failure
|
|
19
20
|
- Compatibility manifest present
|
|
20
21
|
- Evidence bundle attached to release
|
|
22
|
+
- Weekly governance report generated and reviewed before maintainers publish
|
|
21
23
|
|
|
22
24
|
## Evidence
|
|
23
25
|
- Install validation report
|
|
24
26
|
- Rollback verification log
|
|
25
27
|
- Publish dry-run output
|
|
26
28
|
- Integrity and provenance manifest
|
|
29
|
+
- Governance weekly report with trust-tier and gate posture summary
|
|
27
30
|
|
|
28
31
|
## Fallback
|
|
29
32
|
- If automated rollback cannot be guaranteed, the operation must stop before mutation.
|
|
@@ -0,0 +1,9 @@
|
|
|
1
|
+
{
|
|
2
|
+
"schemaVersion": "compatibility-manifest-v1",
|
|
3
|
+
"artifactType": "skill-domain-evidence",
|
|
4
|
+
"domain": "frontend",
|
|
5
|
+
"ides": ["cursor", "windsurf", "copilot", "gemini", "claude", "codex", "cline"],
|
|
6
|
+
"nodeMin": "18",
|
|
7
|
+
"platforms": ["windows", "linux", "macos"],
|
|
8
|
+
"validatedAt": "2026-04-11T12:00:00Z"
|
|
9
|
+
}
|
|
@@ -7,6 +7,8 @@ The frontend domain covers component architecture, state management, performance
|
|
|
7
7
|
- [Accessibility](accessibility.md) - WCAG compliance, keyboard navigation, semantic HTML, color contrast
|
|
8
8
|
- [Motion](motion.md) - Animation patterns, performance, CSS containment
|
|
9
9
|
- [Performance](performance.md) - Memoization, code splitting, bundle gates, profiling
|
|
10
|
+
- [Responsive Delivery](responsive-delivery.md) - Breakpoint behavior, content hierarchy, and interaction ergonomics
|
|
11
|
+
- [Conversion Clarity](conversion-clarity.md) - First-viewport messaging, CTA placement, and friction removal
|
|
10
12
|
|
|
11
13
|
## What Makes Ours Different
|
|
12
14
|
|
|
@@ -21,6 +23,8 @@ The frontend domain covers component architecture, state management, performance
|
|
|
21
23
|
2. `accessibility.md` - Compliance baseline (EXPERT)
|
|
22
24
|
3. `motion.md` - Design patterns and optimization (EXPERT)
|
|
23
25
|
4. `performance.md` - Profiling and gates (EXPERT)
|
|
26
|
+
5. `responsive-delivery.md` - Mobile and desktop behavior contracts (ADVANCE)
|
|
27
|
+
6. `conversion-clarity.md` - UX narrative and action path quality (ADVANCE)
|
|
24
28
|
|
|
25
29
|
## Coverage vs 3 Repos
|
|
26
30
|
|
|
@@ -33,4 +37,13 @@ The frontend domain covers component architecture, state management, performance
|
|
|
33
37
|
|
|
34
38
|
## Default Tier Behavior
|
|
35
39
|
- Use `advance` for typical web apps (1500+ employees)
|
|
36
|
-
- Escalate to `expert` when component library, state complexity, or accessibility/performance tuning is critical
|
|
40
|
+
- Escalate to `expert` when component library, state complexity, or accessibility/performance tuning is critical
|
|
41
|
+
|
|
42
|
+
## Usage Example
|
|
43
|
+
|
|
44
|
+
Use frontend guidance in onboarding and release checkpoints:
|
|
45
|
+
|
|
46
|
+
```bash
|
|
47
|
+
agentic-senior-core init --preset frontend-web
|
|
48
|
+
node ./scripts/frontend-usability-audit.mjs
|
|
49
|
+
```
|
|
@@ -0,0 +1,51 @@
|
|
|
1
|
+
# Conversion Clarity
|
|
2
|
+
|
|
3
|
+
Tier: ADVANCE
|
|
4
|
+
|
|
5
|
+
Conversion clarity ensures users understand value, trust the flow, and can complete primary actions without ambiguity.
|
|
6
|
+
|
|
7
|
+
## First-Viewport Messaging
|
|
8
|
+
|
|
9
|
+
Every conversion-oriented screen should answer three questions immediately:
|
|
10
|
+
|
|
11
|
+
- What is this offering?
|
|
12
|
+
- Why should I continue now?
|
|
13
|
+
- What action should I take first?
|
|
14
|
+
|
|
15
|
+
Avoid generic hero copy and unclear button labels. CTA text should describe outcome, not only interaction.
|
|
16
|
+
|
|
17
|
+
## Friction Mapping
|
|
18
|
+
|
|
19
|
+
Define friction checkpoints per journey:
|
|
20
|
+
|
|
21
|
+
- Input complexity and cognitive load.
|
|
22
|
+
- Validation and error recovery behavior.
|
|
23
|
+
- Payment or confirmation trust signals.
|
|
24
|
+
- Abandonment points from analytics and session replay.
|
|
25
|
+
|
|
26
|
+
Each checkpoint needs an explicit mitigation strategy.
|
|
27
|
+
|
|
28
|
+
## Error and Empty State Quality
|
|
29
|
+
|
|
30
|
+
- Error states must explain cause and provide next action.
|
|
31
|
+
- Empty states must direct users toward meaningful first action.
|
|
32
|
+
- Do not rely on passive placeholders without guidance.
|
|
33
|
+
- Preserve user input when validation fails to reduce retry friction.
|
|
34
|
+
|
|
35
|
+
## Instrumentation Expectations
|
|
36
|
+
|
|
37
|
+
Track conversion quality with consistent events:
|
|
38
|
+
|
|
39
|
+
- Journey start.
|
|
40
|
+
- Step completion.
|
|
41
|
+
- Validation failure categories.
|
|
42
|
+
- Final success and drop-off points.
|
|
43
|
+
|
|
44
|
+
Ensure event names and payload schema are versioned.
|
|
45
|
+
|
|
46
|
+
## Review Checklist
|
|
47
|
+
|
|
48
|
+
- [ ] First viewport communicates value and next action clearly.
|
|
49
|
+
- [ ] Primary CTA labels are specific and outcome-oriented.
|
|
50
|
+
- [ ] Error and empty states contain actionable guidance.
|
|
51
|
+
- [ ] Conversion analytics events are complete and versioned.
|
|
@@ -0,0 +1,41 @@
|
|
|
1
|
+
# Responsive Delivery
|
|
2
|
+
|
|
3
|
+
Tier: ADVANCE
|
|
4
|
+
|
|
5
|
+
Responsive delivery is not just resizing components. It defines how information hierarchy, interaction ergonomics, and loading behavior adapt across screen classes.
|
|
6
|
+
|
|
7
|
+
## Breakpoint Contract
|
|
8
|
+
|
|
9
|
+
Define a small set of supported breakpoints and explicitly map each critical screen to layout behavior:
|
|
10
|
+
|
|
11
|
+
- Mobile baseline for primary one-handed flows.
|
|
12
|
+
- Tablet landscape/portrait handling for mixed navigation density.
|
|
13
|
+
- Desktop behavior for dense data views and power-user shortcuts.
|
|
14
|
+
|
|
15
|
+
## Hierarchy and Readability
|
|
16
|
+
|
|
17
|
+
- Keep primary value proposition and main action in first viewport.
|
|
18
|
+
- Promote one primary CTA and one secondary CTA at most on conversion screens.
|
|
19
|
+
- Prevent layout shift when optional content loads asynchronously.
|
|
20
|
+
- Keep typography scaling consistent with design tokens.
|
|
21
|
+
|
|
22
|
+
## Interaction Ergonomics
|
|
23
|
+
|
|
24
|
+
- Maintain touch target minimum sizes for mobile.
|
|
25
|
+
- Preserve keyboard navigability on desktop and tablet keyboard scenarios.
|
|
26
|
+
- Avoid hover-only critical interactions.
|
|
27
|
+
- Ensure sticky bars and bottom sheets do not hide required form controls.
|
|
28
|
+
|
|
29
|
+
## Validation Workflow
|
|
30
|
+
|
|
31
|
+
1. Capture screenshots for each breakpoint from the same scenario.
|
|
32
|
+
2. Execute keyboard and pointer flow checks on critical journeys.
|
|
33
|
+
3. Verify loading, empty, and error states for each breakpoint class.
|
|
34
|
+
4. Attach responsive evidence to release artifact bundle.
|
|
35
|
+
|
|
36
|
+
## Review Checklist
|
|
37
|
+
|
|
38
|
+
- [ ] Breakpoint behavior is documented per critical screen.
|
|
39
|
+
- [ ] Primary CTA remains clear on all supported viewports.
|
|
40
|
+
- [ ] Touch and keyboard interactions are both functional.
|
|
41
|
+
- [ ] Loading and error states preserve layout stability.
|
|
@@ -0,0 +1 @@
|
|
|
1
|
+
# Frontend skill test fixtures placeholder
|
|
@@ -11,6 +11,8 @@ Deliver frontend experiences that are visually intentional, accessible, and effi
|
|
|
11
11
|
- Motion, animation, and interaction polish
|
|
12
12
|
- Accessibility and keyboard flows
|
|
13
13
|
- Conversion clarity and onboarding flow
|
|
14
|
+
- Performance budgets and render diagnostics
|
|
15
|
+
- Release evidence for visual and interaction quality
|
|
14
16
|
|
|
15
17
|
## Must-Have Checks
|
|
16
18
|
- Feature-driven folder structure
|
|
@@ -19,12 +21,16 @@ Deliver frontend experiences that are visually intentional, accessible, and effi
|
|
|
19
21
|
- Reduced-motion fallback
|
|
20
22
|
- Accessibility baseline pass
|
|
21
23
|
- Responsive behavior verified on mobile and desktop
|
|
24
|
+
- First viewport communicates value proposition and primary action clearly
|
|
25
|
+
- Error and empty states provide explicit next actions
|
|
26
|
+
- Performance budget and regression thresholds are documented per release
|
|
22
27
|
|
|
23
28
|
## Evidence
|
|
24
29
|
- Usability audit result
|
|
25
30
|
- Visual regression output
|
|
26
31
|
- Accessibility checklist result
|
|
27
32
|
- Release notes for motion and interaction changes
|
|
33
|
+
- Performance trend snapshot and remediation notes when regressions occur
|
|
28
34
|
|
|
29
35
|
## Fallback
|
|
30
36
|
- If a feature cannot meet the advance tier, ship standard mode only as a temporary compatibility path.
|
|
@@ -0,0 +1,9 @@
|
|
|
1
|
+
{
|
|
2
|
+
"schemaVersion": "compatibility-manifest-v1",
|
|
3
|
+
"artifactType": "skill-domain-evidence",
|
|
4
|
+
"domain": "fullstack",
|
|
5
|
+
"ides": ["cursor", "windsurf", "copilot", "gemini", "claude", "codex", "cline"],
|
|
6
|
+
"nodeMin": "18",
|
|
7
|
+
"platforms": ["windows", "linux", "macos"],
|
|
8
|
+
"validatedAt": "2026-04-11T12:00:00Z"
|
|
9
|
+
}
|
|
@@ -8,6 +8,7 @@ This domain connects frontend and backend implementation into a single feature-d
|
|
|
8
8
|
- [Feature Slicing](feature-slicing.md) - Organize UI, service, repository, and tests around one business capability
|
|
9
9
|
- [Contracts](contracts.md) - Keep API schemas, DTOs, and frontend types synchronized
|
|
10
10
|
- [End-to-End](end-to-end.md) - Release readiness by verified user journeys and operational gates
|
|
11
|
+
- [Release Coordination](release-coordination.md) - Multi-service rollout ordering, rollback thresholds, and evidence handoff
|
|
11
12
|
|
|
12
13
|
## Operating Model
|
|
13
14
|
- Use `advance` for normal feature development.
|
|
@@ -16,4 +17,11 @@ This domain connects frontend and backend implementation into a single feature-d
|
|
|
16
17
|
## Above-Line Additions
|
|
17
18
|
- Contract drift detection in CI before merge.
|
|
18
19
|
- Backward-compatibility checks for API changes.
|
|
19
|
-
- Release evidence bundle for end-to-end readiness.
|
|
20
|
+
- Release evidence bundle for end-to-end readiness.
|
|
21
|
+
|
|
22
|
+
## Usage Example
|
|
23
|
+
|
|
24
|
+
```bash
|
|
25
|
+
agentic-senior-core init --preset fullstack-product
|
|
26
|
+
node ./scripts/quality-trend-report.mjs
|
|
27
|
+
```
|
|
@@ -0,0 +1,51 @@
|
|
|
1
|
+
# Release Coordination
|
|
2
|
+
|
|
3
|
+
Tier: EXPERT
|
|
4
|
+
|
|
5
|
+
Release coordination in fullstack systems aligns UI rollout, API compatibility, data migration timing, and rollback readiness across teams.
|
|
6
|
+
|
|
7
|
+
## Coordination Matrix
|
|
8
|
+
|
|
9
|
+
Define a shared release matrix before merge:
|
|
10
|
+
|
|
11
|
+
- Frontend deployment window and feature-flag activation point.
|
|
12
|
+
- Backend deployment order and compatibility grace period.
|
|
13
|
+
- Data migration execution and rollback scope.
|
|
14
|
+
- Observability checks required for release acceptance.
|
|
15
|
+
|
|
16
|
+
## Rollout Sequencing
|
|
17
|
+
|
|
18
|
+
Use an order that preserves backward compatibility:
|
|
19
|
+
|
|
20
|
+
1. Deploy backend changes in compatibility mode.
|
|
21
|
+
2. Verify contract and benchmark gates.
|
|
22
|
+
3. Deploy frontend consuming new contract.
|
|
23
|
+
4. Enable feature flags progressively.
|
|
24
|
+
5. Remove compatibility shim in a later release.
|
|
25
|
+
|
|
26
|
+
## Blocker Handling
|
|
27
|
+
|
|
28
|
+
Track blocker categories with explicit owners:
|
|
29
|
+
|
|
30
|
+
- Contract mismatch blockers.
|
|
31
|
+
- Performance regression blockers.
|
|
32
|
+
- Accessibility or conversion regression blockers.
|
|
33
|
+
- Migration and rollback uncertainty blockers.
|
|
34
|
+
|
|
35
|
+
A release can proceed only when blocker list is empty or risk acceptance is approved and documented.
|
|
36
|
+
|
|
37
|
+
## Evidence Handoff
|
|
38
|
+
|
|
39
|
+
Release evidence bundle should include:
|
|
40
|
+
|
|
41
|
+
- End-to-end report for critical journeys.
|
|
42
|
+
- Contract validation and diff summary.
|
|
43
|
+
- Benchmark and quality-trend snapshot.
|
|
44
|
+
- Rollback drill or recovery playbook reference.
|
|
45
|
+
|
|
46
|
+
## Review Checklist
|
|
47
|
+
|
|
48
|
+
- [ ] Rollout sequence keeps consumer/provider compatibility.
|
|
49
|
+
- [ ] Blockers have owner and due date before release review.
|
|
50
|
+
- [ ] Feature flags are mapped to rollback strategy.
|
|
51
|
+
- [ ] Evidence bundle is attached to release decision.
|
|
@@ -0,0 +1 @@
|
|
|
1
|
+
# Fullstack skill test fixtures placeholder
|