@ryuenn3123/agentic-senior-core 3.0.46 → 3.0.48
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/prompts/init-project.md +9 -7
- package/.agent-context/prompts/refactor.md +1 -1
- package/.agent-context/prompts/review-code.md +1 -1
- package/.agent-context/review-checklists/pr-checklist.md +3 -0
- package/.agent-context/rules/api-docs.md +4 -0
- package/.agent-context/rules/architecture.md +16 -2
- package/.agent-context/state/architecture-map.md +3 -3
- package/.agent-context/state/dependency-map.md +2 -2
- package/AGENTS.md +170 -35
- package/CLAUDE.md +1 -44
- package/CONTRIBUTING.md +2 -3
- package/GEMINI.md +1 -44
- package/README.md +28 -22
- package/lib/cli/backup.mjs +37 -0
- package/lib/cli/commands/init.mjs +15 -29
- package/lib/cli/commands/optimize.mjs +2 -48
- package/lib/cli/commands/upgrade.mjs +14 -52
- package/lib/cli/compiler.mjs +25 -95
- package/lib/cli/constants.mjs +1 -9
- package/lib/cli/detector.mjs +0 -1
- package/lib/cli/init-options.mjs +1 -1
- package/lib/cli/project-scaffolder/constants.mjs +1 -0
- package/lib/cli/project-scaffolder/discovery.mjs +2 -0
- package/lib/cli/project-scaffolder/prompt-builders.mjs +9 -5
- package/lib/cli/utils/filesystem.mjs +2 -0
- package/lib/cli/utils/managed-surface.mjs +45 -2
- package/lib/cli/utils.mjs +19 -4
- package/package.json +1 -10
- package/scripts/bump-version.mjs +1 -16
- package/scripts/docs-quality-drift-report.mjs +0 -6
- package/scripts/frontend-usability-audit.mjs +2 -2
- package/scripts/governance-weekly-report.mjs +2 -2
- package/scripts/single-source-lazy-loading-audit.mjs +13 -126
- package/scripts/sync-thin-adapters.mjs +13 -121
- package/scripts/validate/config.mjs +20 -27
- package/scripts/validate/coverage-checks.mjs +9 -76
- package/scripts/validate.mjs +12 -97
- package/.agent-override.md +0 -36
- package/.agents/workflows/init-project.md +0 -12
- package/.agents/workflows/refactor.md +0 -12
- package/.agents/workflows/review-code.md +0 -11
- package/.cursor/mcp.json +0 -10
- package/.cursor/rules/agentic-senior-core.mdc +0 -49
- package/.cursorrules +0 -26
- package/.gemini/instructions.md +0 -44
- package/.github/copilot-instructions.md +0 -44
- package/.github/instructions/agentic-senior-core.instructions.md +0 -48
- package/.github/workflows/benchmark-detection.yml +0 -45
- package/.github/workflows/benchmark-intelligence.yml +0 -50
- package/.github/workflows/docs-quality-drift-report.yml +0 -37
- package/.github/workflows/frontend-usability-gate.yml +0 -36
- package/.github/workflows/governance-weekly-report.yml +0 -43
- package/.github/workflows/publish.yml +0 -32
- package/.github/workflows/release-gate.yml +0 -32
- package/.github/workflows/sbom-compliance.yml +0 -32
- package/.instructions.md +0 -186
- package/.windsurf/rules/agentic-senior-core.md +0 -44
- package/.windsurfrules +0 -26
|
@@ -1,43 +0,0 @@
|
|
|
1
|
-
name: Governance Weekly Report
|
|
2
|
-
|
|
3
|
-
on:
|
|
4
|
-
schedule:
|
|
5
|
-
- cron: '0 3 * * 1'
|
|
6
|
-
workflow_dispatch:
|
|
7
|
-
|
|
8
|
-
permissions:
|
|
9
|
-
contents: read
|
|
10
|
-
|
|
11
|
-
jobs:
|
|
12
|
-
governance-weekly-report:
|
|
13
|
-
runs-on: ubuntu-latest
|
|
14
|
-
timeout-minutes: 15
|
|
15
|
-
env:
|
|
16
|
-
FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: true
|
|
17
|
-
steps:
|
|
18
|
-
- name: Checkout repository
|
|
19
|
-
uses: actions/checkout@v4
|
|
20
|
-
|
|
21
|
-
- name: Setup Node.js
|
|
22
|
-
uses: actions/setup-node@v4
|
|
23
|
-
with:
|
|
24
|
-
node-version: '22'
|
|
25
|
-
|
|
26
|
-
- name: Run quality trend report
|
|
27
|
-
run: |
|
|
28
|
-
node ./scripts/quality-trend-report.mjs > quality-trend-report.json
|
|
29
|
-
test -s quality-trend-report.json
|
|
30
|
-
|
|
31
|
-
- name: Run weekly governance report
|
|
32
|
-
run: |
|
|
33
|
-
node ./scripts/governance-weekly-report.mjs > weekly-governance-report.json
|
|
34
|
-
test -s weekly-governance-report.json
|
|
35
|
-
|
|
36
|
-
- name: Upload governance artifacts
|
|
37
|
-
if: always()
|
|
38
|
-
uses: actions/upload-artifact@v4
|
|
39
|
-
with:
|
|
40
|
-
name: governance-weekly-report
|
|
41
|
-
path: |
|
|
42
|
-
quality-trend-report.json
|
|
43
|
-
weekly-governance-report.json
|
|
@@ -1,32 +0,0 @@
|
|
|
1
|
-
name: publish-to-npm
|
|
2
|
-
|
|
3
|
-
on:
|
|
4
|
-
push:
|
|
5
|
-
branches:
|
|
6
|
-
- main
|
|
7
|
-
|
|
8
|
-
jobs:
|
|
9
|
-
publish:
|
|
10
|
-
runs-on: ubuntu-latest
|
|
11
|
-
steps:
|
|
12
|
-
- name: Checkout repository
|
|
13
|
-
uses: actions/checkout@v4
|
|
14
|
-
|
|
15
|
-
- name: Setup Node.js
|
|
16
|
-
uses: actions/setup-node@v4
|
|
17
|
-
with:
|
|
18
|
-
node-version: 24
|
|
19
|
-
registry-url: 'https://registry.npmjs.org'
|
|
20
|
-
|
|
21
|
-
- name: Install dependencies
|
|
22
|
-
run: npm install
|
|
23
|
-
|
|
24
|
-
- name: Run verification
|
|
25
|
-
run: |
|
|
26
|
-
npm run validate
|
|
27
|
-
npm test
|
|
28
|
-
|
|
29
|
-
- name: Publish to NPM
|
|
30
|
-
run: npm publish --access public
|
|
31
|
-
env:
|
|
32
|
-
NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
|
|
@@ -1,32 +0,0 @@
|
|
|
1
|
-
name: release-gate
|
|
2
|
-
|
|
3
|
-
on:
|
|
4
|
-
push:
|
|
5
|
-
branches:
|
|
6
|
-
- main
|
|
7
|
-
pull_request:
|
|
8
|
-
workflow_dispatch:
|
|
9
|
-
|
|
10
|
-
permissions:
|
|
11
|
-
contents: read
|
|
12
|
-
|
|
13
|
-
jobs:
|
|
14
|
-
release-gate:
|
|
15
|
-
runs-on: ubuntu-latest
|
|
16
|
-
steps:
|
|
17
|
-
- name: Checkout repository
|
|
18
|
-
uses: actions/checkout@v4
|
|
19
|
-
|
|
20
|
-
- name: Setup Node.js
|
|
21
|
-
uses: actions/setup-node@v4
|
|
22
|
-
with:
|
|
23
|
-
node-version: 24
|
|
24
|
-
|
|
25
|
-
- name: Run release gate
|
|
26
|
-
run: node ./scripts/release-gate.mjs > release-gate-report.json
|
|
27
|
-
|
|
28
|
-
- name: Upload release gate report artifact
|
|
29
|
-
uses: actions/upload-artifact@v4
|
|
30
|
-
with:
|
|
31
|
-
name: release-gate-report
|
|
32
|
-
path: release-gate-report.json
|
|
@@ -1,32 +0,0 @@
|
|
|
1
|
-
name: sbom-compliance
|
|
2
|
-
|
|
3
|
-
on:
|
|
4
|
-
push:
|
|
5
|
-
branches:
|
|
6
|
-
- main
|
|
7
|
-
pull_request:
|
|
8
|
-
workflow_dispatch:
|
|
9
|
-
|
|
10
|
-
permissions:
|
|
11
|
-
contents: read
|
|
12
|
-
|
|
13
|
-
jobs:
|
|
14
|
-
generate-sbom:
|
|
15
|
-
runs-on: ubuntu-latest
|
|
16
|
-
steps:
|
|
17
|
-
- name: Checkout repository
|
|
18
|
-
uses: actions/checkout@v4
|
|
19
|
-
|
|
20
|
-
- name: Setup Node.js
|
|
21
|
-
uses: actions/setup-node@v4
|
|
22
|
-
with:
|
|
23
|
-
node-version: 24
|
|
24
|
-
|
|
25
|
-
- name: Generate CycloneDX SBOM
|
|
26
|
-
run: node ./scripts/generate-sbom.mjs > sbom.cdx.json
|
|
27
|
-
|
|
28
|
-
- name: Upload SBOM artifact
|
|
29
|
-
uses: actions/upload-artifact@v4
|
|
30
|
-
with:
|
|
31
|
-
name: sbom-cyclonedx
|
|
32
|
-
path: sbom.cdx.json
|
package/.instructions.md
DELETED
|
@@ -1,186 +0,0 @@
|
|
|
1
|
-
# Agentic-Senior-Core: Unified AI Agent Instructions
|
|
2
|
-
|
|
3
|
-
Bootstrap entrypoint. Resolve the smallest relevant layer set for the current request.
|
|
4
|
-
|
|
5
|
-
## Role
|
|
6
|
-
|
|
7
|
-
Act as a Principal Engineer. Ship maintainable, validated, production-ready work. Use clear plain language in formal artifacts. Do not use emoji.
|
|
8
|
-
|
|
9
|
-
## Authority
|
|
10
|
-
|
|
11
|
-
This repository is governed by a strict instruction contract.
|
|
12
|
-
|
|
13
|
-
Use `.instructions.md` as the canonical baseline. Use `.agent-context/` as technical authority for rules, prompts, checklists, state, and policies. Use `README.md` only for public and developer overview, setup, usage, and user-facing context when stricter governance files conflict.
|
|
14
|
-
|
|
15
|
-
Write instructions as imperative gates:
|
|
16
|
-
- Use direct commands.
|
|
17
|
-
- Prefer short mechanical checks over descriptive prose.
|
|
18
|
-
- Keep root adapters thin.
|
|
19
|
-
- Move detailed policy into `.agent-context/`.
|
|
20
|
-
- Add validation when a rule can drift.
|
|
21
|
-
|
|
22
|
-
## Bootstrap Receipt
|
|
23
|
-
|
|
24
|
-
For non-trivial coding, review, planning, or governance work, emit a concise Bootstrap Receipt before implementation output or file edits:
|
|
25
|
-
- `loaded_files`: files actually read
|
|
26
|
-
- `selected_rules`: files selected for this scope and why
|
|
27
|
-
- `skipped_rules`: out-of-scope categories left unloaded
|
|
28
|
-
- `unreachable_files`: required files that could not be read
|
|
29
|
-
- `validation_plan`: expected checks before completion
|
|
30
|
-
|
|
31
|
-
Keep it short. Do not load every rule just to fill it out.
|
|
32
|
-
|
|
33
|
-
## Command Economy
|
|
34
|
-
|
|
35
|
-
Avoid repeated command output. Do not rerun broad inspections unless edits changed the result. Prefer targeted reads, targeted searches, concise diffs, and final validation gates.
|
|
36
|
-
|
|
37
|
-
## Layer Index
|
|
38
|
-
|
|
39
|
-
### Layer 1: Rules (15 Files) [SCOPE-RESOLVED]
|
|
40
|
-
|
|
41
|
-
Location: `.agent-context/rules/`.
|
|
42
|
-
|
|
43
|
-
Load only relevant rule files. Do not read the entire rule directory by default.
|
|
44
|
-
|
|
45
|
-
Available rules: `naming-conv.md`, `architecture.md`, `security.md`, `performance.md`, `error-handling.md`, `testing.md`, `git-workflow.md`, `efficiency-vs-hype.md`, `api-docs.md`, `microservices.md`, `event-driven.md`, `database-design.md`, `realtime.md`, `frontend-architecture.md`, `docker-runtime.md`.
|
|
46
|
-
|
|
47
|
-
For Docker or Compose work, load `docker-runtime.md` and verify the latest official Docker docs before authoring container assets. For framework or package setup work, use the latest stable compatible dependency set and official setup flow unless a documented compatibility constraint blocks it. Prefer official framework scaffolders when they create the supported project shape; manual file assembly needs a repo, prototype, learning, or architecture reason. New dependencies are allowed when they improve efficiency, delivery time, correctness, accessibility, UX, or maintainability. Do not treat dependency avoidance or vague performance fear as a default reason to skip a modern maintained library.
|
|
48
|
-
|
|
49
|
-
Backend/API routing:
|
|
50
|
-
- Data/schema/persistence: `architecture.md`, `database-design.md`, `performance.md`, `testing.md`.
|
|
51
|
-
- Endpoint/API/error contracts: `architecture.md`, `api-docs.md`, `error-handling.md`, `security.md`, `testing.md`.
|
|
52
|
-
- Auth/secrets/uploads/permissions: `security.md`, `error-handling.md`, `testing.md`.
|
|
53
|
-
- Queue/worker/cron/events/retry: `event-driven.md`, `database-design.md`, `error-handling.md`, `performance.md`, `testing.md`.
|
|
54
|
-
- Multi-service/distributed boundaries: `microservices.md`, `event-driven.md`, `database-design.md`, `api-docs.md`, `architecture.md`.
|
|
55
|
-
|
|
56
|
-
Use the union once when scopes overlap. Do not create framework-specific governance adapters.
|
|
57
|
-
|
|
58
|
-
### Layer 2: Runtime Decision Signals
|
|
59
|
-
|
|
60
|
-
Runtime Decision Signals come from project context, repo evidence, and live research. Runtime signals are evidence gates, not style cues or popularity rankings.
|
|
61
|
-
|
|
62
|
-
For fresh projects, recommend runtime/framework from the brief, constraints, and live official docs before coding. For existing projects, treat detected markers as evidence only. Ignore pattern frequency, external rankings, and remembered defaults. Do not default web projects to Next.js, Tailwind-only styling, shadcn/ui, Vite, or any familiar web stack by habit, and do not avoid them because of this guard when they are the strongest project fit.
|
|
63
|
-
|
|
64
|
-
### Layer 3: Structural Planning Signals
|
|
65
|
-
|
|
66
|
-
Structural Planning Signals use dynamic structural planning from repo context, docs, runtime constraints, and live research. Structural planning signals are not a hard whitelist.
|
|
67
|
-
|
|
68
|
-
For new projects or modules, extract constraints, boundaries, and required docs first. Do not silently choose frameworks or architecture from offline heuristics. If runtime or architecture is unresolved, produce a short recommendation from evidence and live official documentation before coding. Compare at least one plausible alternative when the strongest-looking option is a familiar web default and the user did not explicitly choose it.
|
|
69
|
-
|
|
70
|
-
### Layer 4: Execution Contracts
|
|
71
|
-
|
|
72
|
-
Execution Contracts are dynamic execution contracts from prompts, review checklists, and policy thresholds. Resolve the active contract, then enforce mandatory checks before declaring completion.
|
|
73
|
-
|
|
74
|
-
### Layer 5: Prompts
|
|
75
|
-
|
|
76
|
-
Location: `.agent-context/prompts/`.
|
|
77
|
-
|
|
78
|
-
Load the matching prompt only:
|
|
79
|
-
- `init-project.md` -> create, build, new project, scaffold
|
|
80
|
-
- `refactor.md` -> refactor, improve, clean up, fix
|
|
81
|
-
- `review-code.md` -> review, audit, check, analyze
|
|
82
|
-
- `bootstrap-design.md` -> ui, ux, layout, screen, tailwind, frontend, redesign
|
|
83
|
-
|
|
84
|
-
For UI-only work, load `bootstrap-design.md` and `frontend-architecture.md` first; do not eagerly load unrelated backend-only rules unless the request crosses that boundary. The valid style context is current repo evidence, current brief, and current project docs. External references, prior-chat memory, unrelated-project visuals, and remembered screenshots are tainted unless the user makes them current-task constraints. Treat WCAG 2.2 AA as the hard compliance floor and APCA as advisory perceptual tuning only. Do not require screenshot capture as a baseline dependency.
|
|
85
|
-
|
|
86
|
-
### Layer 6: Governance Modes
|
|
87
|
-
|
|
88
|
-
Governance Modes use dynamic governance context from state files, policies, and repo norms. Apply matching defaults only when relevant.
|
|
89
|
-
|
|
90
|
-
### Layer 7: State and Benchmarks
|
|
91
|
-
|
|
92
|
-
Use `.agent-context/state/` only when the task needs risk zones, dependency boundaries, benchmarks, or continuity metadata.
|
|
93
|
-
|
|
94
|
-
### Layer 8: Policies and Thresholds
|
|
95
|
-
|
|
96
|
-
Use `.agent-context/policies/` for quality gates, release thresholds, and audit posture.
|
|
97
|
-
|
|
98
|
-
### Layer 9: Project Context
|
|
99
|
-
|
|
100
|
-
Use root `README.md` as the public and developer entrypoint for every fresh or existing project. Use `docs/` when present: `project-brief.md`, `architecture-decision-record.md`, `database-schema.md`, `api-contract.md`, `flow-overview.md`, `DESIGN.md`, `design-intent.json`.
|
|
101
|
-
|
|
102
|
-
## Mandatory Triggers
|
|
103
|
-
|
|
104
|
-
### 1. Documentation-First Mode
|
|
105
|
-
|
|
106
|
-
Trigger: docs, documentation, dokumen, `docs/*`, architecture docs, flow docs, API docs, or "lengkapkan docs".
|
|
107
|
-
|
|
108
|
-
1. Load `architecture.md`, `api-docs.md`, and only additional rules required by scope.
|
|
109
|
-
2. Create or refine required docs first: root `README.md` for every fresh or existing project; `docs/project-brief.md`; `docs/architecture-decision-record.md`; `docs/flow-overview.md`; `docs/api-contract.md` for APIs, firmware endpoints, CLI commands, or web application flows; `docs/database-schema.md` for persistent data; and `docs/DESIGN.md` plus `docs/design-intent.json` for UI scope.
|
|
110
|
-
3. Write formal project docs in English by default unless the user asks otherwise.
|
|
111
|
-
4. Stop after documentation when the user only asked for docs. Do not write application, firmware, or UI code until the user asks or approves implementation.
|
|
112
|
-
|
|
113
|
-
### 2. New Project Planning
|
|
114
|
-
|
|
115
|
-
Trigger: create, build, new project, scaffold.
|
|
116
|
-
|
|
117
|
-
1. Resolve relevant rules.
|
|
118
|
-
2. Read `init-project.md`.
|
|
119
|
-
3. Infer constraints, required docs, and boundaries from requirements, repo evidence, docs, and live research.
|
|
120
|
-
4. Recommend runtime/architecture when unresolved.
|
|
121
|
-
5. WAIT for user approval before generating code.
|
|
122
|
-
|
|
123
|
-
### 3. Refactor Mode
|
|
124
|
-
|
|
125
|
-
Trigger: refactor, improve, fix, clean up.
|
|
126
|
-
|
|
127
|
-
1. Resolve relevant rules.
|
|
128
|
-
2. Read `refactor.md`.
|
|
129
|
-
3. Apply active prompt/checklist contracts.
|
|
130
|
-
4. Propose a plan before edits.
|
|
131
|
-
5. WAIT for approval.
|
|
132
|
-
|
|
133
|
-
### 4. Code Review Mode
|
|
134
|
-
|
|
135
|
-
Trigger: review, audit, check, analyze.
|
|
136
|
-
|
|
137
|
-
Load `pr-checklist.md` and `architecture-review.md`, then report defects, risks, regressions, and missing tests first.
|
|
138
|
-
|
|
139
|
-
### 5. UI Design Mode
|
|
140
|
-
|
|
141
|
-
Trigger: ui, ux, layout, screen, tailwind, frontend, redesign.
|
|
142
|
-
|
|
143
|
-
1. Read `bootstrap-design.md` and `frontend-architecture.md`.
|
|
144
|
-
2. Read UI-relevant repo evidence from state, current UI code, and `docs/*`.
|
|
145
|
-
3. Include a one-line Motion/Palette Decision before UI code; product categories are heuristics, not style presets.
|
|
146
|
-
4. Before UI code, record one real-world anchor, one signature motion behavior, and one typographic role contrast.
|
|
147
|
-
5. Ensure `docs/design-intent.json` includes `conceptualAnchor.anchorReference`, top-level `derivedTokenLogic`, `libraryResearchStatus`, `libraryDecisions[]`, and motion/palette decisions.
|
|
148
|
-
6. Generate or refine `docs/DESIGN.md` plus `docs/design-intent.json` before UI implementation.
|
|
149
|
-
7. Keep context isolated; do not eagerly load unrelated backend-only rules.
|
|
150
|
-
8. In UI Design Mode, choose the ambition level proactively. For broad screens or redesigns, treat expressive motion, spatial hierarchy, distinctive composition, and product-specific interaction as the baseline even when the user did not say "rich"; quiet or static surfaces require a concrete product, performance, accessibility, device, or dependency reason.
|
|
151
|
-
9. Do not let conceptual anchors collapse into room, darkroom, counting room, control room, war room, studio, lab, cockpit, or command center by habit. Prefer artifacts, workflows, custody chains, instruments, data behaviors, material systems, editorial systems, service rituals, or interaction mechanisms unless a physical place model is core to the product.
|
|
152
|
-
10. External websites and benchmark examples are candidate evidence for constraints, mechanics, and quality bars only. Do not copy their layout rhythm, palette, component skin, visual metaphor, or brand posture without explicit user approval and product-fit rationale.
|
|
153
|
-
|
|
154
|
-
## Reasoning Chain
|
|
155
|
-
|
|
156
|
-
When rejecting an approach or enforcing a rule, use:
|
|
157
|
-
|
|
158
|
-
```text
|
|
159
|
-
REASONING CHAIN
|
|
160
|
-
Problem: [risk]
|
|
161
|
-
Required Action: [boundary]
|
|
162
|
-
Why Required: [project protection]
|
|
163
|
-
```
|
|
164
|
-
|
|
165
|
-
## Definition of Done
|
|
166
|
-
|
|
167
|
-
Never claim done without:
|
|
168
|
-
1. Relevant rules applied.
|
|
169
|
-
2. PR and architecture checklists considered.
|
|
170
|
-
3. Universal SOP gates satisfied: public and developer root `README.md`; `docs/architecture-decision-record.md`; plus `docs/DESIGN.md` and `docs/design-intent.json` for UI scope.
|
|
171
|
-
4. If `.agent-context/state/active-memory.json` exists and material project progress happened, refresh it while preserving privacy rules and user-owned entries.
|
|
172
|
-
5. MCP validation passed through `npm run validate`.
|
|
173
|
-
|
|
174
|
-
## Knowledge Inventory Checklist
|
|
175
|
-
|
|
176
|
-
Verify reachability when relevant: Layer 1 Rules, Layer 2 Runtime Decision Signals, Layer 3 Structural Planning Signals, Layer 4 Execution Contracts, Layer 5 Prompts, Layer 6 Governance Modes, Layer 7 State, Layer 8 Policies, Layer 9 Project Context.
|
|
177
|
-
|
|
178
|
-
## Operating Gates
|
|
179
|
-
|
|
180
|
-
- Before code: resolve active rules and contract.
|
|
181
|
-
- Before PR: run review checklists.
|
|
182
|
-
- Before deploy: check policy thresholds.
|
|
183
|
-
- Before major refactor: read `architecture-map.md`.
|
|
184
|
-
- Before UI implementation: confirm valid style context, design contract, and required docs.
|
|
185
|
-
|
|
186
|
-
Start here. If `.agent-instructions.md` exists, read it next. Otherwise continue into the relevant layers.
|
|
@@ -1,44 +0,0 @@
|
|
|
1
|
-
# Windsurf Rule - Thin Adapter
|
|
2
|
-
|
|
3
|
-
Adapter Mode: thin
|
|
4
|
-
Adapter Source: .instructions.md
|
|
5
|
-
Canonical Snapshot SHA256: c66b5dfe48a25f0df297a1681aa6bab572da95d2201f09abf3767d38a2934591
|
|
6
|
-
|
|
7
|
-
This repository is governed by a strict instruction contract.
|
|
8
|
-
Use [.instructions.md](../../.instructions.md) as the canonical policy source.
|
|
9
|
-
Use .agent-context/ for technical rules, prompts, checklists, policies, and state.
|
|
10
|
-
Treat README.md as public and developer overview, setup, usage, and user-facing context only when governance files conflict.
|
|
11
|
-
|
|
12
|
-
## Critical Bootstrap Floor
|
|
13
|
-
|
|
14
|
-
- If your host stops at this file, continue the chain manually before coding.
|
|
15
|
-
- Read `.agent-instructions.md` next when it exists.
|
|
16
|
-
- Memory continuity does not replace bootstrap loading.
|
|
17
|
-
- For UI, UX, layout, screen, tailwind, frontend, or redesign requests, load [bootstrap-design.md](../../.agent-context/prompts/bootstrap-design.md) and [frontend-architecture.md](../../.agent-context/rules/frontend-architecture.md) before code edits.
|
|
18
|
-
- For UI scope, include a one-line Motion/Palette Decision in the Bootstrap Receipt; product categories are heuristics, not style presets.
|
|
19
|
-
- For UI scope, create or refine `docs/DESIGN.md` and `docs/design-intent.json` before UI implementation.
|
|
20
|
-
- For documentation-first requests, create or refine required project docs in English by default and do not write application, firmware, or UI code until the user asks or approves.
|
|
21
|
-
- Create or refine root README.md as the public and developer entrypoint before implementation.
|
|
22
|
-
- For backend, API, data, auth, error, event, queue, worker, or distributed-system requests, load only relevant global rules from .agent-context/rules/ ([link](../../.agent-context/rules)).
|
|
23
|
-
- For ecosystem, framework, dependency, or Docker claims, perform live web research.
|
|
24
|
-
- Resolve runtime choices from project evidence and live official documentation; resolve structural planning from constraints and architecture boundaries.
|
|
25
|
-
|
|
26
|
-
## Mandatory Bootstrap Chain
|
|
27
|
-
|
|
28
|
-
1. Load [.instructions.md](../../.instructions.md).
|
|
29
|
-
2. Load `.agent-instructions.md` when present.
|
|
30
|
-
3. Load only relevant files from .agent-context/rules/ ([link](../../.agent-context/rules)).
|
|
31
|
-
4. Apply matching prompts from .agent-context/prompts/ ([link](../../.agent-context/prompts)).
|
|
32
|
-
5. Enforce .agent-context/review-checklists/ ([link](../../.agent-context/review-checklists/pr-checklist.md)).
|
|
33
|
-
6. Use .agent-context/state/ ([link](../../.agent-context/state)) and .agent-context/policies/ ([link](../../.agent-context/policies)) only when relevant.
|
|
34
|
-
7. Use project docs and live evidence for runtime, dependency, and architecture claims.
|
|
35
|
-
|
|
36
|
-
## Bootstrap Receipt
|
|
37
|
-
|
|
38
|
-
For non-trivial coding, review, planning, or governance work, produce a short Bootstrap Receipt before implementation output: `loaded_files`, `selected_rules`, `skipped_rules`, `unreachable_files`, and `validation_plan`.
|
|
39
|
-
|
|
40
|
-
## Completion Gate
|
|
41
|
-
|
|
42
|
-
Run [pr-checklist.md](../../.agent-context/review-checklists/pr-checklist.md) before declaring work complete.
|
|
43
|
-
|
|
44
|
-
If this adapter drifts from canonical behavior, refresh from [.instructions.md](../../.instructions.md) and update the hash metadata.
|
package/.windsurfrules
DELETED
|
@@ -1,26 +0,0 @@
|
|
|
1
|
-
# .windsurfrules - Legacy Thin Adapter
|
|
2
|
-
|
|
3
|
-
Generated by Agentic-Senior-Core CLI v3.0.46
|
|
4
|
-
Adapter Mode: legacy-thin
|
|
5
|
-
Adapter Source: .agent-instructions.md when present; fallback .instructions.md
|
|
6
|
-
Canonical baseline: .instructions.md
|
|
7
|
-
|
|
8
|
-
This file is kept only for older Windsurf discovery.
|
|
9
|
-
Read .agent-instructions.md for the compiled rulebook when present.
|
|
10
|
-
Use .instructions.md as the canonical policy source.
|
|
11
|
-
|
|
12
|
-
Mandatory load floor:
|
|
13
|
-
1. Read .agent-instructions.md when present; otherwise read .instructions.md.
|
|
14
|
-
2. Load only relevant .agent-context/rules/ by task scope.
|
|
15
|
-
3. Apply matching .agent-context/prompts/ contracts.
|
|
16
|
-
4. Enforce .agent-context/review-checklists/ before completion.
|
|
17
|
-
5. Use .agent-context/state/ and .agent-context/policies/ only when relevant.
|
|
18
|
-
6. Resolve Runtime Decision Signals from repo evidence and live official docs.
|
|
19
|
-
7. Resolve Structural Planning Signals from constraints and architecture boundaries.
|
|
20
|
-
|
|
21
|
-
Current bridges:
|
|
22
|
-
- Cursor: .cursor/rules/agentic-senior-core.mdc
|
|
23
|
-
- Windsurf: .windsurf/rules/agentic-senior-core.md
|
|
24
|
-
- Claude: CLAUDE.md
|
|
25
|
-
- Gemini: GEMINI.md and .gemini/instructions.md
|
|
26
|
-
- Copilot: .github/copilot-instructions.md and .github/instructions/agentic-senior-core.instructions.md
|