all-hands-cli 0.1.14 → 0.1.15
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.
|
@@ -80,6 +80,7 @@ Prompt files reference suites in `validation_suites` frontmatter. During executi
|
|
|
80
80
|
|
|
81
81
|
- **External tooling** (xctrace, simctl, playwright, etc.) — Document explicitly: commands, flags, use cases inline with motivations. Stable and unfamiliar to agents by default. Example from xcode-automation: `xcrun xctrace record --template 'Time Profiler' --device '<UDID>' --attach '<PID>'` — flags, ordering constraints, and PID discovery are external tool knowledge that belongs in the suite.
|
|
82
82
|
- **Internal codebase commands** — Document patterns, not inventories: teach discovery (`package.json` scripts, `--help`), naming conventions, motivations for test categories. Pattern-based suites age gracefully; command inventories require constant maintenance.
|
|
83
|
+
- **Anti-pattern — exhaustive command tables**: A deterministic section listing every `test:*` command as individual rows goes stale as suites evolve. Instead: document the minimum CI gate command explicitly, teach the naming pattern, point to the source of truth (e.g., `package.json`), and explain how to choose scope. The agent reads the source at execution time — always fresher than a static table.
|
|
83
84
|
|
|
84
85
|
## Decision Tree Requirement
|
|
85
86
|
|
|
@@ -117,6 +118,24 @@ New suites: draft, then test on a feature branch before marking guidance as prov
|
|
|
117
118
|
|
|
118
119
|
The plan/handoff document persists as the hypothesis record for future work.
|
|
119
120
|
|
|
121
|
+
## Established Practice vs Unvalidated Ideas
|
|
122
|
+
|
|
123
|
+
Suites contain two kinds of guidance, both authoritative:
|
|
124
|
+
|
|
125
|
+
- **Established practice**: Verified hands-on. Stated authoritatively — agents follow directly.
|
|
126
|
+
- **Unvalidated ideas**: Worth pursuing but not yet exercised. Authoritative as direction — agents encountering them should attempt, assess feasibility, and document outcomes.
|
|
127
|
+
|
|
128
|
+
Ideas carry an implicit mandate: try to make them work, then capture what happened (see Learnings Destination). Over time, ideas that prove out become established practice. Ideas that prove infeasible get revised or removed. This is the crystallization lifecycle applied to the documentation itself.
|
|
129
|
+
|
|
130
|
+
## Learnings Destination
|
|
131
|
+
|
|
132
|
+
When agents discover something during validation:
|
|
133
|
+
|
|
134
|
+
- **Suite-level learnings** (about the validation *practice*) → update the suite doc directly. The suite is what agents read — improvements compound immediately. Examples: tool flag doesn't work on this OS, one approach is more reliable than another.
|
|
135
|
+
- **Task-specific learnings** (about *what was validated*) → knowledge compounding via prompt files or knowledge docs. Examples: endpoint edge case behavior, migration quirks.
|
|
136
|
+
|
|
137
|
+
Distinction: if it helps any agent validating in this domain regardless of task, it belongs in the suite. If it's specific to a feature, it compounds through knowledge docs.
|
|
138
|
+
|
|
120
139
|
## Cross-Referencing Between Suites
|
|
121
140
|
|
|
122
141
|
- **Reference** for complex multi-step setup — point to the authoritative suite's decision tree
|