@vpxa/aikit 0.1.78 → 0.1.79

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/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@vpxa/aikit",
3
- "version": "0.1.78",
3
+ "version": "0.1.79",
4
4
  "type": "module",
5
5
  "description": "Local-first AI developer toolkit — knowledge base, code analysis, context management, and developer tools for LLM agents",
6
6
  "license": "MIT",
@@ -30,6 +30,7 @@
30
30
  "scaffold/",
31
31
  "!scaffold/__tests__/",
32
32
  "!scaffold/definitions/",
33
+ "scaffold/definitions/exclusions.mjs",
33
34
  "!scaffold/_preview/",
34
35
  "!scaffold/generate.mjs",
35
36
  "!scaffold/adapters/",
@@ -0,0 +1,58 @@
1
+ /**
2
+ * Permanent Exclusions — things aikit intentionally will NOT do.
3
+ *
4
+ * Each exclusion includes rationale grounded in the Bitter Lesson:
5
+ * systems should leverage computation over hand-crafted features.
6
+ * These exclusions are injected into copilot-instructions.md.
7
+ */
8
+
9
+ export const PERMANENT_EXCLUSIONS = [
10
+ {
11
+ name: 'Hard-coded lint rules',
12
+ rationale:
13
+ 'Project-specific linting belongs in ESLint or Biome config, not baked into agent instructions. Configurable tooling and automated checks scale better than hand-crafted rules embedded in prompts.',
14
+ bitterLessonSafe: true,
15
+ },
16
+
17
+ {
18
+ name: 'Framework-specific boilerplate generation',
19
+ rationale:
20
+ 'Framework CLIs and IDE scaffolds already generate boilerplate from evolving upstream knowledge. Delegating to those computational systems is safer than freezing hand-written templates into aikit instructions.',
21
+ bitterLessonSafe: true,
22
+ },
23
+
24
+ {
25
+ name: 'Git workflow enforcement',
26
+ rationale:
27
+ 'Branch policies, commit formatting, and merge gates belong in git hooks and CI where they can be enforced automatically. Reliable computation beats informal agent-side reminders and hand-crafted behavior rules.',
28
+ bitterLessonSafe: true,
29
+ },
30
+
31
+ {
32
+ name: 'IDE-specific keybinding and config guidance',
33
+ rationale:
34
+ 'Editor shortcuts, panel layouts, and workspace settings are IDE concerns that change across clients and teams. Runtime tooling and local editor config are the right computational layer, not static agent instructions.',
35
+ bitterLessonSafe: true,
36
+ },
37
+
38
+ {
39
+ name: 'Package manager lock file manipulation',
40
+ rationale:
41
+ 'Lock files should be produced by the package manager and verified in CI or release pipelines, not manually curated by agent policy. Deterministic tool execution is more robust than hand-crafted lockfile guidance.',
42
+ bitterLessonSafe: true,
43
+ },
44
+
45
+ {
46
+ name: 'Hard-coded file naming conventions',
47
+ rationale:
48
+ 'Naming rules vary by repository and should live in project generators, linters, or review automation. Letting configurable computation enforce conventions scales better than embedding brittle file-name doctrine in prompts.',
49
+ bitterLessonSafe: true,
50
+ },
51
+
52
+ {
53
+ name: 'Runtime environment variable validation',
54
+ rationale:
55
+ 'Environment validation belongs in application startup code, schemas, and deployment checks where real runtime state is available. Computed validation with executable code outperforms hand-crafted agent assumptions about env shape.',
56
+ bitterLessonSafe: true,
57
+ },
58
+ ];