hub-launch 1.18.0 → 1.20.0
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/CHANGELOG.md +29 -0
- package/README.md +101 -435
- package/dist/commands/{merge.d.ts → approve.d.ts} +2 -2
- package/dist/commands/approve.d.ts.map +1 -0
- package/dist/commands/{merge.js → approve.js} +4 -4
- package/dist/commands/approve.js.map +1 -0
- package/dist/commands/init.d.ts.map +1 -1
- package/dist/commands/init.js +10 -27
- package/dist/commands/init.js.map +1 -1
- package/dist/commands/interactive.js +6 -6
- package/dist/commands/interactive.js.map +1 -1
- package/dist/commands/launch.d.ts +0 -2
- package/dist/commands/launch.d.ts.map +1 -1
- package/dist/commands/launch.js +1 -16
- package/dist/commands/launch.js.map +1 -1
- package/dist/commands/schedule.d.ts.map +1 -1
- package/dist/commands/schedule.js +5 -20
- package/dist/commands/schedule.js.map +1 -1
- package/dist/commands/script.d.ts +1 -1
- package/dist/commands/script.d.ts.map +1 -1
- package/dist/commands/script.js +2 -2
- package/dist/commands/script.js.map +1 -1
- package/dist/config/command-names.d.ts +1 -1
- package/dist/config/command-names.js +1 -1
- package/dist/config/command-names.js.map +1 -1
- package/dist/index.js +2 -2
- package/dist/index.js.map +1 -1
- package/dist/scripts/{merge-local.d.ts → approve-local.d.ts} +1 -1
- package/dist/scripts/approve-local.d.ts.map +1 -0
- package/dist/scripts/{merge-local.js → approve-local.js} +7 -7
- package/dist/scripts/approve-local.js.map +1 -0
- package/dist/scripts/{merge-remote.d.ts → approve-remote.d.ts} +3 -3
- package/dist/scripts/approve-remote.d.ts.map +1 -0
- package/dist/scripts/{merge-remote.js → approve-remote.js} +6 -6
- package/dist/scripts/approve-remote.js.map +1 -0
- package/dist/templates/planning-instructions.md +54 -0
- package/dist/templates/proceed-instructions.md +66 -8
- package/dist/templates/skills/{hula-merge → hula-approve}/SKILL.md +15 -15
- package/dist/templates/skills/hula-confirm/SKILL.md +18 -1
- package/dist/templates/skills/hula-create/SKILL.md +1 -1
- package/dist/templates/skills/hula-fix/SKILL.md +2 -2
- package/dist/templates/skills/hula-help/SKILL.md +3 -3
- package/dist/templates/skills/hula-info/SKILL.md +1 -1
- package/dist/templates/skills/hula-launch/SKILL.md +2 -2
- package/dist/templates/skills/hula-plan/SKILL.md +21 -12
- package/dist/templates/skills/hula-schedule/SKILL.md +1 -1
- package/dist/templates/skills/hula-upload/SKILL.md +1 -1
- package/dist/templates/skills/hula-verify/SKILL.md +1 -1
- package/dist/types/config.schema.d.ts +0 -6
- package/dist/types/config.schema.d.ts.map +1 -1
- package/dist/types/config.schema.js +0 -3
- package/dist/types/config.schema.js.map +1 -1
- package/dist/utils/ephemeral-credentials.d.ts +8 -10
- package/dist/utils/ephemeral-credentials.d.ts.map +1 -1
- package/dist/utils/ephemeral-credentials.js +8 -12
- package/dist/utils/ephemeral-credentials.js.map +1 -1
- package/package.json +1 -1
- package/scripts/postinstall.mjs +1 -1
- package/dist/commands/merge.d.ts.map +0 -1
- package/dist/commands/merge.js.map +0 -1
- package/dist/scripts/merge-local.d.ts.map +0 -1
- package/dist/scripts/merge-local.js.map +0 -1
- package/dist/scripts/merge-remote.d.ts.map +0 -1
- package/dist/scripts/merge-remote.js.map +0 -1
|
@@ -229,6 +229,18 @@ Don't worry about perfection - the inline validation step (Phase 5) will identif
|
|
|
229
229
|
|
|
230
230
|
After generating the draft plan, proceed directly to Phase 5.
|
|
231
231
|
|
|
232
|
+
#### Pre-Save Quality Check
|
|
233
|
+
|
|
234
|
+
Before the plan file is written to disk (Phase 6), do a quick self-check of the DRAFT you just generated. This is a lightweight sweep to fix obvious gaps inline — it is **not** a new gate and **not** a place to ask fresh questions (that is Phase 1's and `/hula-confirm`'s job). **Failing an item does not block saving** — Phase 6 still saves the DRAFT, same as today. Just fix what you can before writing the file, to cut down on later `/hula-confirm` round-trips.
|
|
235
|
+
|
|
236
|
+
Check the draft for:
|
|
237
|
+
|
|
238
|
+
- [ ] **Self-contained** — no "as we discussed", "per our conversation", or similar chat-history references; every fact is stated directly.
|
|
239
|
+
- [ ] **File paths exist** — every file path referenced in the plan actually exists in the codebase (spot-check the ones you're least sure about).
|
|
240
|
+
- [ ] **Pattern references have `file:line`** — every "follow the pattern in X" / "same approach as X" reference includes a concrete `file:line` (or `file` + line range).
|
|
241
|
+
- [ ] **Plan Summary present** — the `## Plan Summary` block is present directly under the H1 title.
|
|
242
|
+
- [ ] **No un-surfaced `❓`** — no `❓` open question was silently left unresolved. Any real open question should already have been raised during Phase 1 clarification; this is a final sweep, not a new place to introduce one.
|
|
243
|
+
|
|
232
244
|
### Phase 5: Auto-Continue to Confirmation
|
|
233
245
|
|
|
234
246
|
After generating and saving the draft plan file (following Phase 6 below), inform the user that the plan has been created and **immediately proceed** to the validation workflow in the same session.
|
|
@@ -307,6 +319,28 @@ When generating the plan content (in Phase 3), follow this structure:
|
|
|
307
319
|
- Clear, concise description of the feature/fix
|
|
308
320
|
- Should be suitable as a GitHub issue title
|
|
309
321
|
|
|
322
|
+
### Plan Summary
|
|
323
|
+
|
|
324
|
+
> **Always include this block.** It appears as an unnumbered `## Plan Summary` heading directly under the H1 title, before "## Problem Statement". It is the 30-second version of the plan — a reader who stops here should still get the gist. Unlike the optional diagram below, this block is **never** omitted.
|
|
325
|
+
|
|
326
|
+
Write 3–5 bullets covering:
|
|
327
|
+
|
|
328
|
+
- **What / why** — one line: what this plan does and the problem it solves.
|
|
329
|
+
- **Key decision(s)** — the most important choice(s) made during planning (e.g. "approach A over B because …").
|
|
330
|
+
- **Most important file(s)** — the one or two files that change the most.
|
|
331
|
+
- **Priority / complexity** — reuse the existing labels: Priority (Critical/High/Medium/Low) and complexity (Simple/Medium/Complex).
|
|
332
|
+
|
|
333
|
+
Example:
|
|
334
|
+
|
|
335
|
+
```markdown
|
|
336
|
+
## Plan Summary
|
|
337
|
+
|
|
338
|
+
- **What/why**: Adds rate limiting to the GitHub API client so bulk operations stop hitting 403s.
|
|
339
|
+
- **Key decision**: Token-bucket in the existing client wrapper (not a new middleware layer) to avoid touching every call site.
|
|
340
|
+
- **Most important file**: `src/services/github/GitHubService.ts`.
|
|
341
|
+
- **Priority/complexity**: High priority, Medium complexity.
|
|
342
|
+
```
|
|
343
|
+
|
|
310
344
|
### 2. Problem Statement
|
|
311
345
|
|
|
312
346
|
**[2-3 sentences describing what problem this solves or what feature this adds]**
|
|
@@ -379,6 +413,8 @@ When generating the plan content (in Phase 3), follow this structure:
|
|
|
379
413
|
|
|
380
414
|
**High-level approach**: [Strategic approach to solving this problem]
|
|
381
415
|
|
|
416
|
+
> **Optional ASCII diagram.** When the solution spans more than one component/service calling each other, or a multi-step flow, include **one** small ASCII/box-and-arrow diagram here to make the shape obvious at a glance. **ASCII only — never Mermaid, PlantUML, or image syntax.** Use boxes for components and arrows (`──▶`, `│`, `▼`) for flow/dependency direction, and keep it to a handful of boxes. **Omit it entirely for single-file or otherwise simple changes** — forcing a diagram onto trivial plans reintroduces the exact "overwhelming" problem this format is fixing. Follow the ASCII style used elsewhere in this repo's tooling (e.g. the diagram examples in `.claude/commands/hula-research.md`).
|
|
417
|
+
|
|
382
418
|
#### Key Components
|
|
383
419
|
|
|
384
420
|
1. **[Component/Area 1]**
|
|
@@ -461,6 +497,16 @@ Example format:
|
|
|
461
497
|
- [ ] Add JSDoc comments to all public methods
|
|
462
498
|
```
|
|
463
499
|
|
|
500
|
+
> **Fold sections 6–11 (Edge Cases & Considerations through Dependencies & Related Work) inside exactly one collapsible `<details>` block**, so a reviewer or launcher reads the always-visible sections 1–5 first and only expands the deeper detail when they need it. In the generated plan, emit this opening tag immediately before "### 6. Edge Cases & Considerations":
|
|
501
|
+
>
|
|
502
|
+
> ```markdown
|
|
503
|
+
> <details>
|
|
504
|
+
> <summary><b>Implementation Detail</b></summary>
|
|
505
|
+
>
|
|
506
|
+
> ```
|
|
507
|
+
>
|
|
508
|
+
> (Note the blank line after `<summary>` so GitHub renders the inner markdown.) Keep sections 6–11 in this same order with their internal content and heading text unchanged, then close the block with `</details>` after section 11 (see the note at the end of section 11). **Sections 1–5 are never wrapped — always directly visible.**
|
|
509
|
+
|
|
464
510
|
### 6. Edge Cases & Considerations
|
|
465
511
|
|
|
466
512
|
#### Edge Cases to Handle
|
|
@@ -473,6 +519,7 @@ Example format:
|
|
|
473
519
|
|
|
474
520
|
- ⚠️ **[Challenge 1]**: [Description and how to address it]
|
|
475
521
|
- ⚠️ **[Challenge 2]**: [Description and how to address it]
|
|
522
|
+
- ❓ **[Open Question]**: [Optional. Only for anything that could not be fully resolved even after clarification rounds — should be rare by design, since real open questions are meant to be surfaced during Phase 1 clarification. Use the same bold-label style as the `⚠️` challenges above.]
|
|
476
523
|
|
|
477
524
|
#### Security Considerations
|
|
478
525
|
|
|
@@ -609,6 +656,13 @@ Clear, testable criteria that define "done". Each criterion should be specific a
|
|
|
609
656
|
- Fixes #[issue-number] (if applicable)
|
|
610
657
|
- See also: [Link to related discussion or documentation]
|
|
611
658
|
|
|
659
|
+
> **Close the fold here.** After the section 11 content above, emit the closing tag to end the `<details>` block opened before section 6:
|
|
660
|
+
>
|
|
661
|
+
> ```markdown
|
|
662
|
+
>
|
|
663
|
+
> </details>
|
|
664
|
+
> ```
|
|
665
|
+
|
|
612
666
|
## Writing Guidelines for Plans
|
|
613
667
|
|
|
614
668
|
### Be Specific, Not Vague
|
|
@@ -66,14 +66,15 @@ Any ambiguity or missing context = implementation failure.
|
|
|
66
66
|
Every plan must have:
|
|
67
67
|
|
|
68
68
|
1. **Title** (H1) - Descriptive, suitable for GitHub issue
|
|
69
|
-
2. **
|
|
70
|
-
3. **
|
|
71
|
-
4. **
|
|
72
|
-
5. **
|
|
73
|
-
6. **
|
|
74
|
-
7. **
|
|
75
|
-
8. **
|
|
76
|
-
9. **
|
|
69
|
+
2. **Plan Summary** - Unnumbered `## Plan Summary` block directly after the Title, before Problem Statement: 3–5 bullets (what/why, key decision(s), most important file(s), priority/complexity)
|
|
70
|
+
3. **Problem Statement** - Current state vs desired state, why needed
|
|
71
|
+
4. **Requirements** - Functional, technical, non-functional (all three)
|
|
72
|
+
5. **Proposed Solution** - High-level approach, key components
|
|
73
|
+
6. **Implementation Steps** - Phased tasks with specific file paths
|
|
74
|
+
7. **Technical Considerations** - Dependencies, config changes, security
|
|
75
|
+
8. **Testing Strategy** - Unit tests, integration tests, manual testing
|
|
76
|
+
9. **Documentation Updates** - README, relevant docs/ pages, code comments
|
|
77
|
+
10. **Acceptance Criteria** - Measurable success conditions
|
|
77
78
|
|
|
78
79
|
**Validation approach:**
|
|
79
80
|
- Check all sections present
|
|
@@ -126,6 +127,62 @@ Every plan must have:
|
|
|
126
127
|
- Ensure edge cases are tested
|
|
127
128
|
- Add test templates if missing
|
|
128
129
|
|
|
130
|
+
### 6. Scope: One Plan = One PR
|
|
131
|
+
|
|
132
|
+
Every plan launches as exactly one pull request, and a PR is only valuable if a
|
|
133
|
+
human can review it in one sitting and verification can check it meaningfully.
|
|
134
|
+
Each launch is also budgeted for one PR's worth of sandbox time. Before a plan
|
|
135
|
+
passes validation, judge whether it fits in one PR.
|
|
136
|
+
|
|
137
|
+
**Signals a plan is oversized (judge holistically — no single number is a hard rule):**
|
|
138
|
+
|
|
139
|
+
- More than ~10 acceptance criteria
|
|
140
|
+
- More than ~3 implementation phases, especially phases that could merge independently
|
|
141
|
+
- Multiple unrelated subsystems in one plan (e.g. auth AND payments AND admin UI)
|
|
142
|
+
- Greenfield language: "build a complete app / platform / site with …"
|
|
143
|
+
- The resulting diff could not be reviewed carefully in one sitting
|
|
144
|
+
|
|
145
|
+
**If the plan fits one PR:** say nothing about scope. This check is invisible
|
|
146
|
+
for normal plans.
|
|
147
|
+
|
|
148
|
+
**If the plan is oversized, STOP before the Launch Offer** and present a split
|
|
149
|
+
proposal:
|
|
150
|
+
|
|
151
|
+
```
|
|
152
|
+
⚠️ This plan is about N PRs, not 1.
|
|
153
|
+
|
|
154
|
+
Plans this size produce PRs too large to review or verify meaningfully — and
|
|
155
|
+
each launch is sized for one PR's worth of sandbox time.
|
|
156
|
+
|
|
157
|
+
I can split it into a sequence, each independently planned, launched, and
|
|
158
|
+
verified:
|
|
159
|
+
|
|
160
|
+
1. `01-<slug>` — <one-line scope>
|
|
161
|
+
2. `02-<slug>` — <one-line scope>
|
|
162
|
+
3. ...
|
|
163
|
+
|
|
164
|
+
Split it this way? (Each becomes its own plan file — launch them one at a
|
|
165
|
+
time as each PR merges.)
|
|
166
|
+
```
|
|
167
|
+
|
|
168
|
+
**On an affirmative reply:**
|
|
169
|
+
|
|
170
|
+
1. Create a subfolder under the plans directory named after the feature
|
|
171
|
+
(e.g. `.hublaunch/plans/<feature-slug>/`).
|
|
172
|
+
2. Write one plan file per part using the normal filename convention, with the
|
|
173
|
+
sequence number in the slug (e.g. `YYYY-MM-DD-HH:MM-01-scaffold.md`). Each
|
|
174
|
+
part MUST be fully self-contained — the implementing agent sees only its own
|
|
175
|
+
plan — and MUST state its prerequisites explicitly ("Builds on the merged PR
|
|
176
|
+
from `01-scaffold`: assumes the Next.js skeleton and CI workflow exist").
|
|
177
|
+
3. Run the full validation framework above on each part.
|
|
178
|
+
4. Offer to launch part `01` only. Later parts launch as their predecessors
|
|
179
|
+
merge — never launch a part whose prerequisite PR is unmerged.
|
|
180
|
+
|
|
181
|
+
**On a negative reply:** respect it. Scope is a strong recommendation, not a
|
|
182
|
+
gate the user cannot override — validate the plan as-is, note the oversize
|
|
183
|
+
warning in the validation summary so the choice is recorded, and continue to
|
|
184
|
+
the Launch Offer.
|
|
185
|
+
|
|
129
186
|
## MCQ Question Guidelines
|
|
130
187
|
|
|
131
188
|
### When to Ask Questions
|
|
@@ -197,6 +254,7 @@ This helps users provide coherent answers.
|
|
|
197
254
|
2. **Missing sections** → Add templates
|
|
198
255
|
- Add "## Testing Strategy" with unit/integration/manual subsections
|
|
199
256
|
- Add "## Edge Cases" with common patterns
|
|
257
|
+
- ⚠️ **Preserve the `<details>` fold**: newer plans wrap sections 6–11 (Edge Cases & Considerations through Dependencies & Related Work) inside one `<details><summary><b>Implementation Detail</b></summary> … </details>` block. When auto-adding a missing section that falls within 6–11, insert it **inside** that existing `<details>` block — never append a flat, unwrapped section 6–11 header after it, and never flatten the wrapper. If the plan predates this format (no fold present), add the section normally.
|
|
200
258
|
|
|
201
259
|
3. **Obvious file paths** → Use codebase search
|
|
202
260
|
- "Update the GitHub service" → `src/services/github/GitHubService.ts`
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
|
-
name: hula-
|
|
3
|
-
description:
|
|
2
|
+
name: hula-approve
|
|
3
|
+
description: "Approve (step 2 of 2): merge the verified PR and clean everything up — branches, worktrees, and your local main. Use when the user approves the work or asks to merge, complete, or close a PR."
|
|
4
4
|
disable-model-invocation: true
|
|
5
5
|
argument-hint: "[issue-number]"
|
|
6
6
|
allowed-tools: Bash Read
|
|
@@ -19,7 +19,7 @@ Your job is to:
|
|
|
19
19
|
|
|
20
20
|
1. **Detect merge path** — check for local fix session + worktree, or fall back to remote-only
|
|
21
21
|
2. **If local session exists**: commit/push changes, merge PR, clean up worktree + session
|
|
22
|
-
3. **If remote-only**: merge PR directly via `hula
|
|
22
|
+
3. **If remote-only**: merge PR directly via `hula approve`
|
|
23
23
|
4. **Report results**
|
|
24
24
|
|
|
25
25
|
The main working tree is **never modified** — all local operations happen in the fix worktree (if one exists).
|
|
@@ -37,7 +37,7 @@ User input: $ARGUMENTS
|
|
|
37
37
|
|
|
38
38
|
**Priority 2: Check user input**
|
|
39
39
|
|
|
40
|
-
- Look for explicit issue number in the `/hula-
|
|
40
|
+
- Look for explicit issue number in the `/hula-approve` invocation (e.g. `/hula-approve 42` or `/hula-approve #42`)
|
|
41
41
|
- Look for pattern: `YizYah/<repo>#\d+` or `#\d+` in user input
|
|
42
42
|
|
|
43
43
|
**Priority 3: Check tracked issues**
|
|
@@ -52,8 +52,8 @@ User input: $ARGUMENTS
|
|
|
52
52
|
❌ No issue number found.
|
|
53
53
|
|
|
54
54
|
Usage:
|
|
55
|
-
- /hula-
|
|
56
|
-
- /hula-
|
|
55
|
+
- /hula-approve (auto-detect from fix session or tracked issues)
|
|
56
|
+
- /hula-approve 42 (explicit issue number)
|
|
57
57
|
```
|
|
58
58
|
|
|
59
59
|
Stop execution here. Do not proceed.
|
|
@@ -130,7 +130,7 @@ Suggested test command: npm test
|
|
|
130
130
|
Generate a commit message based on the issue number, files changed, and nature of changes, then run the local-merge script — it handles commit, push, merge, worktree removal, and session cleanup in one terminal approval:
|
|
131
131
|
|
|
132
132
|
```bash
|
|
133
|
-
hula script
|
|
133
|
+
hula script approve-local -- <issue-number> "<worktreePath>" "fix(#42): <generated-message>"
|
|
134
134
|
```
|
|
135
135
|
|
|
136
136
|
The script outputs JSON with `status`, `committed`, `filesChanged`, `worktreeRemoved`, and `sessionCleaned`.
|
|
@@ -209,12 +209,12 @@ Follow this path when no local fix session/worktree exists. This is the common p
|
|
|
209
209
|
Run the remote-merge script — it merges the PR directly on GitHub and cleans up any stale session file in one terminal approval:
|
|
210
210
|
|
|
211
211
|
```bash
|
|
212
|
-
hula script
|
|
212
|
+
hula script approve-remote -- <issue-number>
|
|
213
213
|
```
|
|
214
214
|
|
|
215
215
|
The script outputs JSON with `status`, `issueNumber`, `sessionCleaned`, and `localUpdated`.
|
|
216
216
|
|
|
217
|
-
The script captures the `hula
|
|
217
|
+
The script captures the `hula approve` CLI output and streams it to your terminal,
|
|
218
218
|
so the **specific reason and remediation** for any skipped local update appears
|
|
219
219
|
above the JSON line. Read it — that's the source of truth for what happened.
|
|
220
220
|
|
|
@@ -308,7 +308,7 @@ The PR has conflicts with the base branch.
|
|
|
308
308
|
Options:
|
|
309
309
|
1. Resolve conflicts via GitHub PR web UI
|
|
310
310
|
2. If local worktree exists: resolve in worktree at <worktreePath>
|
|
311
|
-
3. Run /hula-
|
|
311
|
+
3. Run /hula-approve again after resolving
|
|
312
312
|
```
|
|
313
313
|
|
|
314
314
|
### CI Checks Failing
|
|
@@ -348,8 +348,8 @@ Try: cd <worktreePath> && git push
|
|
|
348
348
|
Check the PR on GitHub: <PR-URL>
|
|
349
349
|
```
|
|
350
350
|
|
|
351
|
-
For Path A: `Session preserved — run /hula-
|
|
352
|
-
For Path B: `Run /hula-
|
|
351
|
+
For Path A: `Session preserved — run /hula-approve again after resolving.`
|
|
352
|
+
For Path B: `Run /hula-approve again after resolving.`
|
|
353
353
|
|
|
354
354
|
## Important Notes
|
|
355
355
|
|
|
@@ -362,7 +362,7 @@ The merge command automatically detects whether to use the local worktree path o
|
|
|
362
362
|
|
|
363
363
|
This covers all scenarios:
|
|
364
364
|
|
|
365
|
-
- `/hula-fix` → `/hula-
|
|
365
|
+
- `/hula-fix` → `/hula-approve` on the same machine (Path A)
|
|
366
366
|
- The implementation agent created the PR on GitHub via `/hula-launch` (Path B)
|
|
367
367
|
- Another contributor's PR (Path B)
|
|
368
368
|
- Previous fix session already cleaned up (Path B)
|
|
@@ -377,14 +377,14 @@ The fix worktree is removed after a successful merge. This:
|
|
|
377
377
|
|
|
378
378
|
On failure, the worktree is preserved so you can:
|
|
379
379
|
|
|
380
|
-
- Fix issues and retry `/hula-
|
|
380
|
+
- Fix issues and retry `/hula-approve`
|
|
381
381
|
- Manually clean up with: `git worktree remove "<path>" --force`
|
|
382
382
|
- Or: `hula worktree cleanup`
|
|
383
383
|
|
|
384
384
|
### Session File Lifecycle
|
|
385
385
|
|
|
386
386
|
- Created by `/hula-fix`
|
|
387
|
-
- Preserved if `/hula-
|
|
387
|
+
- Preserved if `/hula-approve` fails (so you can retry)
|
|
388
388
|
- Deleted after successful merge OR cleaned up if stale (worktree missing)
|
|
389
389
|
|
|
390
390
|
## Session File Format
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: hula-confirm
|
|
3
|
-
description:
|
|
3
|
+
description: Re-validate a plan until it's self-contained and launch-ready (runs automatically after /hula-plan). Use when the user asks to confirm, validate, or refine a plan they've edited.
|
|
4
4
|
disable-model-invocation: true
|
|
5
5
|
argument-hint: "[plan-file-path]"
|
|
6
6
|
allowed-tools: Bash Read
|
|
@@ -83,6 +83,7 @@ Perform these validation checks:
|
|
|
83
83
|
|
|
84
84
|
**Required sections checklist:**
|
|
85
85
|
- ✅ Title (H1) - Clear and descriptive
|
|
86
|
+
- ✅ Plan Summary - Unnumbered `## Plan Summary` block directly after Title, before Problem Statement (what/why, key decision(s), most important file(s), priority/complexity)
|
|
86
87
|
- ✅ Problem Statement - Why this is needed
|
|
87
88
|
- ✅ Requirements - Functional, technical, non-functional
|
|
88
89
|
- ✅ Proposed Solution - High-level approach
|
|
@@ -95,6 +96,7 @@ Perform these validation checks:
|
|
|
95
96
|
**Auto-fix:**
|
|
96
97
|
- Add missing section headers with placeholder text
|
|
97
98
|
- Note which sections need user input to complete
|
|
99
|
+
- ⚠️ Preserve the `<details>` fold: newer plans wrap sections 6–11 (Edge Cases & Considerations through Dependencies & Related Work) in one `<details><summary><b>Implementation Detail</b></summary> … </details>` block. When auto-adding a missing section within 6–11, insert it **inside** that existing block — never append a flat, unwrapped header or flatten the wrapper. If the plan predates this format (no fold present), add the section normally.
|
|
98
100
|
|
|
99
101
|
**Flag for user:**
|
|
100
102
|
- Sections present but too vague or incomplete
|
|
@@ -156,6 +158,21 @@ Perform these validation checks:
|
|
|
156
158
|
- Complex testing scenarios needing user input
|
|
157
159
|
- Unclear test assertions or expected outcomes
|
|
158
160
|
|
|
161
|
+
#### 2.6 Scope Check (One Plan = One PR)
|
|
162
|
+
|
|
163
|
+
Every plan launches as exactly one PR, and each launch is sized for one PR's
|
|
164
|
+
worth of sandbox time. Judge whether the plan fits: too many acceptance
|
|
165
|
+
criteria (~10+), independently-mergeable phases (~4+), multiple unrelated
|
|
166
|
+
subsystems, or "build a complete app" scope all signal an oversized plan.
|
|
167
|
+
|
|
168
|
+
- **Fits one PR** → say nothing about scope (the check is invisible).
|
|
169
|
+
- **Oversized** → STOP before the Launch Offer and propose splitting into a
|
|
170
|
+
numbered sequence of self-contained plans, launched one at a time as each
|
|
171
|
+
predecessor merges. Follow the "Scope: One Plan = One PR" section of
|
|
172
|
+
`hula instructions proceed` for the exact message format and split workflow.
|
|
173
|
+
- The user can decline — validate as-is, record the oversize warning in the
|
|
174
|
+
summary, and continue.
|
|
175
|
+
|
|
159
176
|
### Step 3: Present Validation Summary & MCQ Questions
|
|
160
177
|
|
|
161
178
|
After analysis, present findings in this format:
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: hula-create
|
|
3
|
-
description:
|
|
3
|
+
description: "Legacy: create a GitHub issue from the current plan without launching (the modern flow is /hula-plan → launch). Use only when the user explicitly asks for hula-create."
|
|
4
4
|
disable-model-invocation: true
|
|
5
5
|
argument-hint: <tracking-name> [--handoff <user>] [--priority <level>] [--attach <files>]
|
|
6
6
|
allowed-tools: Bash Read
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: hula-fix
|
|
3
|
-
description: Fix
|
|
3
|
+
description: Fix gaps or bugs on a PR branch in an isolated worktree — your working tree is never touched. Use when the user describes a problem to fix on a PR.
|
|
4
4
|
disable-model-invocation: true
|
|
5
5
|
argument-hint: <problem description> or <owner/repo#N> <problem description>
|
|
6
6
|
allowed-tools: Bash Read
|
|
@@ -161,7 +161,7 @@ Branch: <pr-branch>
|
|
|
161
161
|
Next steps:
|
|
162
162
|
- Review the changes in the PR
|
|
163
163
|
- Run tests if needed
|
|
164
|
-
- When ready to merge: /hula-
|
|
164
|
+
- When ready to merge: /hula-approve
|
|
165
165
|
```
|
|
166
166
|
|
|
167
167
|
## Error Handling
|
|
@@ -63,7 +63,7 @@ Pick ONE line matching the state:
|
|
|
63
63
|
What do you need help with?
|
|
64
64
|
|
|
65
65
|
1. Getting Started — install, login, init, your first plan → launch → merge cycle
|
|
66
|
-
2. The Core Workflow — what /hula-plan, /hula-launch, /hula-verify, /hula-fix, /hula-
|
|
66
|
+
2. The Core Workflow — what /hula-plan, /hula-launch, /hula-verify, /hula-fix, /hula-approve each do
|
|
67
67
|
3. Commands Reference — look up any hula CLI command or /hula-* skill
|
|
68
68
|
4. Configuration — .hublaunch/hublaunch.config.js basics
|
|
69
69
|
5. Something else — just ask your question
|
|
@@ -79,7 +79,7 @@ Read `README.md`'s "Quick Start" and "Requirements" sections (and the "Core Work
|
|
|
79
79
|
2. Install — `npm install -g hub-launch` (or `pnpm add -g hub-launch`).
|
|
80
80
|
3. `hula init` — initializes `.hublaunch/hublaunch.config.js`. If State Check showed **Fresh**, offer to run it now (see "What you're allowed to run").
|
|
81
81
|
4. `hula login` — authenticates GitHub + hula-project. If **Initialized, not logged in**, offer to run it now.
|
|
82
|
-
5. First cycle — `/hula-plan <description>` → `/hula-launch <name>` → `/hula-verify` → `/hula-
|
|
82
|
+
5. First cycle — `/hula-plan <description>` → `/hula-launch <name>` → `/hula-verify` → `/hula-approve`. Point to Topic: The Core Workflow for details on each.
|
|
83
83
|
|
|
84
84
|
## Topic: The Core Workflow
|
|
85
85
|
|
|
@@ -90,7 +90,7 @@ Read the "Core Workflow" section of `README.md` live. Explain each step in plain
|
|
|
90
90
|
- `/hula-launch <name>` — creates the GitHub issue, runs the AI coding session in an isolated cloud container, opens a PR.
|
|
91
91
|
- `/hula-verify` — checks the PR against the plan's acceptance criteria.
|
|
92
92
|
- `/hula-fix <instructions>` — addresses gaps found by verify, or anything else you want changed on the PR branch.
|
|
93
|
-
- `/hula-
|
|
93
|
+
- `/hula-approve` — merges the PR, cleans up, fast-forwards local `main`.
|
|
94
94
|
- Mention `/hula-info`, `/hula-schedule`, `/hula-confirm` as supporting skills, one line each, only if the user wants more than the core cycle.
|
|
95
95
|
|
|
96
96
|
## Topic: Commands Reference
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: hula-info
|
|
3
|
-
description:
|
|
3
|
+
description: "Peek at a launched run: live logs, PR diff, initial summary, lessons, or the launching session id. Use when the user asks how a run is going or wants to see its output."
|
|
4
4
|
disable-model-invocation: true
|
|
5
5
|
argument-hint: "[issue-name] [--logs|--lastLogs|--diff|--initial|--lessons|--clientSessionId]"
|
|
6
6
|
allowed-tools: Bash Read
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: hula-launch
|
|
3
|
-
description: Launch a GitHub issue
|
|
3
|
+
description: "Launch a validated plan: creates the GitHub issue and starts the cloud run that ends in a verified PR (offered automatically after /hula-plan). Use when the user asks to launch a plan."
|
|
4
4
|
disable-model-invocation: true
|
|
5
5
|
argument-hint: <branch-name> [<plan-path>] [--handoff <username>] [--test] [--skip-regression] [--kill] [--kill-and-relaunch]
|
|
6
6
|
allowed-tools: Bash Read
|
|
@@ -111,7 +111,7 @@ The `cliOutput` already says whether a task was cancelled (`Cancelled '<branch>'
|
|
|
111
111
|
**Next Steps:**
|
|
112
112
|
- Use `/hula-fix <problem>` to make corrections
|
|
113
113
|
- Use `/hula-verify` to check implementation against the plan
|
|
114
|
-
- Use `/hula-
|
|
114
|
+
- Use `/hula-approve` when ready to merge
|
|
115
115
|
```
|
|
116
116
|
|
|
117
117
|
## Important Notes
|
|
@@ -1,8 +1,8 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: hula-plan
|
|
3
|
-
description:
|
|
3
|
+
description: "Plan (step 1 of 2): describe what you want built — drafts an implementation plan, validates it until it stands on its own, then offers to launch. Use when the user asks to plan, build, or implement something."
|
|
4
4
|
disable-model-invocation: true
|
|
5
|
-
argument-hint: <
|
|
5
|
+
argument-hint: <what you want built> [--folder <subfolder>] [--autoLaunch [--test] [--handoff <username>]]
|
|
6
6
|
allowed-tools: Bash Read
|
|
7
7
|
---
|
|
8
8
|
|
|
@@ -31,6 +31,7 @@ The user will describe a feature or issue. Your job is to:
|
|
|
31
31
|
|
|
32
32
|
Issue description: $ARGUMENTS
|
|
33
33
|
Folder (optional): Parsed from $ARGUMENTS if --folder flag is provided
|
|
34
|
+
Auto-launch (optional): Parsed from $ARGUMENTS if --autoLaunch flag is provided (optionally combined with --test and/or --handoff <username>, both otherwise unused until the Launch Offer)
|
|
34
35
|
|
|
35
36
|
## Additional Context
|
|
36
37
|
|
|
@@ -90,13 +91,14 @@ Present your findings before asking questions:
|
|
|
90
91
|
Generate a complete markdown document that includes:
|
|
91
92
|
|
|
92
93
|
1. **Title**: Clear H1 heading suitable for a GitHub issue
|
|
93
|
-
2. **
|
|
94
|
-
3. **
|
|
95
|
-
4. **
|
|
96
|
-
5. **
|
|
97
|
-
6. **
|
|
98
|
-
7. **
|
|
99
|
-
8. **
|
|
94
|
+
2. **Plan Summary**: Unnumbered `## Plan Summary` block directly under the Title — 3–5 bullets (what/why, key decision(s), most important file(s), priority/complexity)
|
|
95
|
+
3. **Problem Statement**: Context and motivation
|
|
96
|
+
4. **Proposed Solution**: High-level approach
|
|
97
|
+
5. **Implementation Steps**: Detailed, actionable tasks organized in phases
|
|
98
|
+
6. **Technical Considerations**: Dependencies, config, security, etc.
|
|
99
|
+
7. **Testing Strategy**: Unit, integration, and manual tests
|
|
100
|
+
8. **Documentation Updates**: What docs need updating
|
|
101
|
+
9. **Acceptance Criteria**: Clear completion conditions
|
|
100
102
|
|
|
101
103
|
The plan should be immediately actionable by a developer familiar with the codebase.
|
|
102
104
|
|
|
@@ -144,6 +146,13 @@ Read `hula instructions proceed` and execute the full validation workflow agains
|
|
|
144
146
|
> ⚠️ Auto-validation could not complete. Run `/hula-confirm <path>` to resume.
|
|
145
147
|
|
|
146
148
|
where `<path>` is the plan file path.
|
|
147
|
-
- **Finish with the Launch Offer** — after validation completes, execute the "Launch Offer" section of `hula instructions proceed` (issue-name resolution, the launch question, and launching on an affirmative reply). Never launch without an affirmative reply.
|
|
148
|
-
|
|
149
|
-
|
|
149
|
+
- **Finish with the Launch Offer** — after validation completes, execute the "Launch Offer" section of `hula instructions proceed` (issue-name resolution, the launch question, and launching on an affirmative reply). Never launch without an affirmative reply — **unless `--autoLaunch` was present in the original `$ARGUMENTS`** (see below).
|
|
150
|
+
- **`--autoLaunch` skips the Launch Offer's confirmation sub-step only.** If `--autoLaunch` was present in `$ARGUMENTS`:
|
|
151
|
+
1. Still perform the Launch Offer's "1. Resolve the issue name" step exactly as documented there (conversation-mention wins, else the plan-filename-slug default) — resolution itself is unchanged.
|
|
152
|
+
2. Skip "2. Ask the launch question" and "3. Interpret the reply" entirely — do not ask, do not wait.
|
|
153
|
+
3. Print exactly (substituting the resolved name): `🚀 --autoLaunch set — launching as \`<issueName>\`…`
|
|
154
|
+
4. Immediately perform the Launch Offer's "4. Execute the launch" step: read `.agents/skills/hula-launch/SKILL.md` and execute its workflow with `<issueName> <planPath>`.
|
|
155
|
+
5. If `--test` and/or `--handoff <username>` were also present in `$ARGUMENTS`, pass them through to the launch — same as the Launch Offer's reply table does for a manual reply containing those flags.
|
|
156
|
+
- **Without `--autoLaunch`**, behavior is completely unchanged: ask and wait as today.
|
|
157
|
+
|
|
158
|
+
**Note:** The plan is saved locally. When you run `/hula-launch`, the plan is automatically synced to `origin/main` before the GitHub issue is created and the implementation begins — no separate upload step needed. Because validation ends with the Launch Offer, an affirmative reply runs the `/hula-launch` workflow for the user automatically; they can also decline and run `/hula-launch` themselves later. `/hula-confirm` remains available as a standalone command for re-validation at any time. If `--autoLaunch` was passed to `/hula-plan`, the launch runs automatically once validation completes — no reply needed.
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: hula-schedule
|
|
3
|
-
description: Run
|
|
3
|
+
description: Run or schedule autonomous actions on the server (e.g. a nightly harden audit) — author, list, update, or cancel them in plain language. Use for recurring or one-off background actions.
|
|
4
4
|
disable-model-invocation: true
|
|
5
5
|
argument-hint: <action | description | list | show <id> | run now <id> | cancel <id> | update ...> [on <entry-point>] [outcome pr|plan|feedback] [schedule <when>] [pr-policy always|skip-if-open|close-previous]
|
|
6
6
|
allowed-tools: Bash Read Write Edit
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: hula-upload
|
|
3
|
-
description:
|
|
3
|
+
description: Sync the current plan to origin/main via a temporary worktree (runs automatically during launch). Use when the user asks to upload or sync a plan.
|
|
4
4
|
disable-model-invocation: true
|
|
5
5
|
argument-hint: "[plan-file-path]"
|
|
6
6
|
allowed-tools: Bash Read
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: hula-verify
|
|
3
|
-
description:
|
|
3
|
+
description: "Full verification report: checks the PR against its plan, criterion by criterion (a summary score is already posted automatically at PR time). Use when asked to verify, review, or check a PR against its plan."
|
|
4
4
|
disable-model-invocation: true
|
|
5
5
|
argument-hint: "[issue-number]"
|
|
6
6
|
allowed-tools: Bash Read
|
|
@@ -142,8 +142,6 @@ export declare const ConfigSchema: z.ZodObject<{
|
|
|
142
142
|
hulaApiKey: z.ZodOptional<z.ZodString>;
|
|
143
143
|
hulaProject: z.ZodOptional<z.ZodString>;
|
|
144
144
|
anthropicApiKey: z.ZodOptional<z.ZodString>;
|
|
145
|
-
daytonaApiKey: z.ZodOptional<z.ZodString>;
|
|
146
|
-
daytonaTier: z.ZodDefault<z.ZodNumber>;
|
|
147
145
|
containerResources: z.ZodOptional<z.ZodObject<{
|
|
148
146
|
cpu: z.ZodOptional<z.ZodNumber>;
|
|
149
147
|
memory: z.ZodOptional<z.ZodNumber>;
|
|
@@ -471,7 +469,6 @@ export declare const ConfigSchema: z.ZodObject<{
|
|
|
471
469
|
pollIntervalSeconds: number;
|
|
472
470
|
pollingProvider: "hula-server" | "github";
|
|
473
471
|
usageTier: "free" | "pro";
|
|
474
|
-
daytonaTier: number;
|
|
475
472
|
browserHeadless: "never" | "auto" | "always";
|
|
476
473
|
worktreeBasePath: string;
|
|
477
474
|
projectOwner?: string | undefined;
|
|
@@ -483,7 +480,6 @@ export declare const ConfigSchema: z.ZodObject<{
|
|
|
483
480
|
hulaApiKey?: string | undefined;
|
|
484
481
|
hulaProject?: string | undefined;
|
|
485
482
|
anthropicApiKey?: string | undefined;
|
|
486
|
-
daytonaApiKey?: string | undefined;
|
|
487
483
|
containerResources?: {
|
|
488
484
|
cpu?: number | undefined;
|
|
489
485
|
memory?: number | undefined;
|
|
@@ -592,8 +588,6 @@ export declare const ConfigSchema: z.ZodObject<{
|
|
|
592
588
|
hulaApiKey?: string | undefined;
|
|
593
589
|
hulaProject?: string | undefined;
|
|
594
590
|
anthropicApiKey?: string | undefined;
|
|
595
|
-
daytonaApiKey?: string | undefined;
|
|
596
|
-
daytonaTier?: number | undefined;
|
|
597
591
|
containerResources?: {
|
|
598
592
|
cpu?: number | undefined;
|
|
599
593
|
memory?: number | undefined;
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"config.schema.d.ts","sourceRoot":"","sources":["../../src/types/config.schema.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AAQxB,QAAA,MAAM,uBAAuB;;;;;;;;;EAK3B,CAAC;AAEH,QAAA,MAAM,iBAAiB;;;;;;;;;EAGrB,CAAC;AAEH,QAAA,MAAM,cAAc;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;EAGlB,CAAC;AAEH,QAAA,MAAM,WAAW;;;;;;;;;;;;;;;;;;;;;EAOf,CAAC;AAGH,QAAA,MAAM,iBAAiB;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;EAYrB,CAAC;AAGH,MAAM,MAAM,uBAAuB,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,uBAAuB,CAAC,CAAC;AAC9E,MAAM,MAAM,iBAAiB,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,iBAAiB,CAAC,CAAC;AAClE,MAAM,MAAM,cAAc,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,cAAc,CAAC,CAAC;AAC5D,MAAM,MAAM,WAAW,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,WAAW,CAAC,CAAC;AACtD,MAAM,MAAM,iBAAiB,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,iBAAiB,CAAC,CAAC;AAGlE,eAAO,MAAM,YAAY
|
|
1
|
+
{"version":3,"file":"config.schema.d.ts","sourceRoot":"","sources":["../../src/types/config.schema.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AAQxB,QAAA,MAAM,uBAAuB;;;;;;;;;EAK3B,CAAC;AAEH,QAAA,MAAM,iBAAiB;;;;;;;;;EAGrB,CAAC;AAEH,QAAA,MAAM,cAAc;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;EAGlB,CAAC;AAEH,QAAA,MAAM,WAAW;;;;;;;;;;;;;;;;;;;;;EAOf,CAAC;AAGH,QAAA,MAAM,iBAAiB;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;EAYrB,CAAC;AAGH,MAAM,MAAM,uBAAuB,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,uBAAuB,CAAC,CAAC;AAC9E,MAAM,MAAM,iBAAiB,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,iBAAiB,CAAC,CAAC;AAClE,MAAM,MAAM,cAAc,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,cAAc,CAAC,CAAC;AAC5D,MAAM,MAAM,WAAW,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,WAAW,CAAC,CAAC;AACtD,MAAM,MAAM,iBAAiB,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,iBAAiB,CAAC,CAAC;AAGlE,eAAO,MAAM,YAAY;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;EAoKvB,CAAC;AACH,MAAM,MAAM,MAAM,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,YAAY,CAAC,CAAC;AAGlD,eAAO,MAAM,cAAc,EAAE,MAc5B,CAAC"}
|
|
@@ -68,8 +68,6 @@ export const ConfigSchema = z.object({
|
|
|
68
68
|
hulaApiKey: z.string().optional(),
|
|
69
69
|
hulaProject: z.string().optional(), // Format: "owner/repo" - set during login when API key is project-scoped
|
|
70
70
|
anthropicApiKey: z.string().optional(),
|
|
71
|
-
daytonaApiKey: z.string().optional(),
|
|
72
|
-
daytonaTier: z.number().int().min(1).max(4).default(1),
|
|
73
71
|
containerResources: z
|
|
74
72
|
.object({
|
|
75
73
|
cpu: z.number().int().min(1).max(32).optional(),
|
|
@@ -202,6 +200,5 @@ export const DEFAULT_CONFIG = {
|
|
|
202
200
|
pollingProvider: 'hula-server',
|
|
203
201
|
browserHeadless: 'auto',
|
|
204
202
|
worktreeBasePath: '.hula-worktrees',
|
|
205
|
-
daytonaTier: 1,
|
|
206
203
|
};
|
|
207
204
|
//# sourceMappingURL=config.schema.js.map
|
|
@@ -1 +1 @@
|
|
|
1
|
-
{"version":3,"file":"config.schema.js","sourceRoot":"","sources":["../../src/types/config.schema.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AACxB,OAAO,EACL,mBAAmB,EACnB,6BAA6B,EAC7B,yBAAyB,GAC1B,MAAM,oBAAoB,CAAC;AAE5B,2BAA2B;AAC3B,MAAM,uBAAuB,GAAG,CAAC,CAAC,MAAM,CAAC;IACvC,QAAQ,EAAE,CAAC;SACR,IAAI,CAAC,CAAC,QAAQ,EAAE,SAAS,EAAE,SAAS,EAAE,QAAQ,CAAC,CAAC;SAChD,OAAO,CAAC,QAAQ,CAAC;IACpB,UAAU,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,QAAQ,EAAE;CAClC,CAAC,CAAC;AAEH,MAAM,iBAAiB,GAAG,CAAC,CAAC,MAAM,CAAC;IACjC,QAAQ,EAAE,CAAC,CAAC,IAAI,CAAC,CAAC,OAAO,EAAE,OAAO,EAAE,QAAQ,EAAE,MAAM,CAAC,CAAC,CAAC,OAAO,CAAC,MAAM,CAAC;IACtE,UAAU,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,QAAQ,EAAE;CAClC,CAAC,CAAC;AAEH,MAAM,cAAc,GAAG,CAAC,CAAC,MAAM,CAAC;IAC9B,UAAU,EAAE,uBAAuB,CAAC,QAAQ,EAAE;IAC9C,cAAc,EAAE,iBAAiB,CAAC,QAAQ,EAAE;CAC7C,CAAC,CAAC;AAEH,MAAM,WAAW,GAAG,CAAC,CAAC,MAAM,CAAC;IAC3B,iBAAiB,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,QAAQ,EAAE;IACxC,kBAAkB,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,QAAQ,EAAE;IACzC,aAAa,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,QAAQ,EAAE;IACpC,YAAY,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,QAAQ,EAAE;IACnC,WAAW,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,QAAQ,EAAE;IAClC,UAAU,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,QAAQ,EAAE;CAClC,CAAC,CAAC;AAEH,uCAAuC;AACvC,MAAM,iBAAiB,GAAG,CAAC,CAAC,MAAM,CAAC;IACjC,QAAQ,EAAE,CAAC;SACR,IAAI,CAAC,CAAC,OAAO,EAAE,OAAO,EAAE,UAAU,EAAE,QAAQ,EAAE,MAAM,CAAC,CAAC;SACtD,OAAO,CAAC,OAAO,CAAC;IACnB,SAAS,EAAE,CAAC;SACT,MAAM,CAAC;QACN,UAAU,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,QAAQ,EAAE;QACjC,aAAa,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,QAAQ,EAAE;QACpC,YAAY,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,QAAQ,EAAE;QACnC,YAAY,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,QAAQ,EAAE;KACpC,CAAC;SACD,QAAQ,EAAE;CACd,CAAC,CAAC;AASH,gBAAgB;AAChB,MAAM,CAAC,MAAM,YAAY,GAAG,CAAC,CAAC,MAAM,CAAC;IACnC,aAAa,EAAE,CAAC,CAAC,IAAI,CAAC,CAAC,QAAQ,EAAE,QAAQ,EAAE,OAAO,CAAC,CAAC,CAAC,OAAO,CAAC,OAAO,CAAC;IACrE,QAAQ,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,OAAO,CAAC,kBAAkB,CAAC;IAEhD,wEAAwE;IACxE,0EAA0E;IAC1E,kEAAkE;IAClE,OAAO,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,QAAQ,EAAE;IAE9B,YAAY,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,OAAO,CAAC,8BAA8B,CAAC;IAChE,sBAAsB,EAAE,CAAC;SACtB,IAAI,CAAC,CAAC,cAAc,EAAE,kBAAkB,CAAC,CAAC;SAC1C,OAAO,CAAC,kBAAkB,CAAC;IAC9B,WAAW,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,OAAO,CAAC,CAAC,CAAC;IAClC,mBAAmB,EAAE,CAAC,CAAC,OAAO,EAAE,CAAC,OAAO,CAAC,KAAK,CAAC;IAE/C,uBAAuB;IACvB,YAAY,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,OAAO,CAAC,MAAM,CAAC;IAExC,qBAAqB;IACrB,WAAW,EAAE,CAAC,CAAC,KAAK,CAAC,CAAC,CAAC,MAAM,EAAE,CAAC,CAAC,QAAQ,EAAE;IAE3C,0DAA0D;IAC1D,aAAa,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,QAAQ,EAAE;IACpC,SAAS,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,QAAQ,EAAE;IAChC,YAAY,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,QAAQ,EAAE;IACnC,eAAe,EAAE,CAAC,CAAC,OAAO,EAAE,CAAC,OAAO,CAAC,KAAK,CAAC;IAC3C,mBAAmB,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,yBAAyB,CAAC,CAAC,OAAO,CAAC,6BAA6B,CAAC;IACrG,eAAe,EAAE,CAAC,CAAC,IAAI,CAAC,CAAC,aAAa,EAAE,QAAQ,CAAC,CAAC,CAAC,OAAO,CAAC,aAAa,CAAC;IAEzE,sCAAsC;IACtC,SAAS,EAAE,CAAC,CAAC,IAAI,CAAC,CAAC,MAAM,EAAE,KAAK,CAAC,CAAC,CAAC,OAAO,CAAC,MAAM,CAAC;IAClD,cAAc,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,QAAQ,EAAE;IACrC,UAAU,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,QAAQ,EAAE;IACjC,WAAW,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,QAAQ,EAAE,EAAE,yEAAyE;IAC7G,eAAe,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,QAAQ,EAAE;IACtC,
|
|
1
|
+
{"version":3,"file":"config.schema.js","sourceRoot":"","sources":["../../src/types/config.schema.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,CAAC,EAAE,MAAM,KAAK,CAAC;AACxB,OAAO,EACL,mBAAmB,EACnB,6BAA6B,EAC7B,yBAAyB,GAC1B,MAAM,oBAAoB,CAAC;AAE5B,2BAA2B;AAC3B,MAAM,uBAAuB,GAAG,CAAC,CAAC,MAAM,CAAC;IACvC,QAAQ,EAAE,CAAC;SACR,IAAI,CAAC,CAAC,QAAQ,EAAE,SAAS,EAAE,SAAS,EAAE,QAAQ,CAAC,CAAC;SAChD,OAAO,CAAC,QAAQ,CAAC;IACpB,UAAU,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,QAAQ,EAAE;CAClC,CAAC,CAAC;AAEH,MAAM,iBAAiB,GAAG,CAAC,CAAC,MAAM,CAAC;IACjC,QAAQ,EAAE,CAAC,CAAC,IAAI,CAAC,CAAC,OAAO,EAAE,OAAO,EAAE,QAAQ,EAAE,MAAM,CAAC,CAAC,CAAC,OAAO,CAAC,MAAM,CAAC;IACtE,UAAU,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,QAAQ,EAAE;CAClC,CAAC,CAAC;AAEH,MAAM,cAAc,GAAG,CAAC,CAAC,MAAM,CAAC;IAC9B,UAAU,EAAE,uBAAuB,CAAC,QAAQ,EAAE;IAC9C,cAAc,EAAE,iBAAiB,CAAC,QAAQ,EAAE;CAC7C,CAAC,CAAC;AAEH,MAAM,WAAW,GAAG,CAAC,CAAC,MAAM,CAAC;IAC3B,iBAAiB,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,QAAQ,EAAE;IACxC,kBAAkB,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,QAAQ,EAAE;IACzC,aAAa,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,QAAQ,EAAE;IACpC,YAAY,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,QAAQ,EAAE;IACnC,WAAW,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,QAAQ,EAAE;IAClC,UAAU,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,QAAQ,EAAE;CAClC,CAAC,CAAC;AAEH,uCAAuC;AACvC,MAAM,iBAAiB,GAAG,CAAC,CAAC,MAAM,CAAC;IACjC,QAAQ,EAAE,CAAC;SACR,IAAI,CAAC,CAAC,OAAO,EAAE,OAAO,EAAE,UAAU,EAAE,QAAQ,EAAE,MAAM,CAAC,CAAC;SACtD,OAAO,CAAC,OAAO,CAAC;IACnB,SAAS,EAAE,CAAC;SACT,MAAM,CAAC;QACN,UAAU,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,QAAQ,EAAE;QACjC,aAAa,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,QAAQ,EAAE;QACpC,YAAY,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,QAAQ,EAAE;QACnC,YAAY,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,QAAQ,EAAE;KACpC,CAAC;SACD,QAAQ,EAAE;CACd,CAAC,CAAC;AASH,gBAAgB;AAChB,MAAM,CAAC,MAAM,YAAY,GAAG,CAAC,CAAC,MAAM,CAAC;IACnC,aAAa,EAAE,CAAC,CAAC,IAAI,CAAC,CAAC,QAAQ,EAAE,QAAQ,EAAE,OAAO,CAAC,CAAC,CAAC,OAAO,CAAC,OAAO,CAAC;IACrE,QAAQ,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,OAAO,CAAC,kBAAkB,CAAC;IAEhD,wEAAwE;IACxE,0EAA0E;IAC1E,kEAAkE;IAClE,OAAO,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,QAAQ,EAAE;IAE9B,YAAY,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,OAAO,CAAC,8BAA8B,CAAC;IAChE,sBAAsB,EAAE,CAAC;SACtB,IAAI,CAAC,CAAC,cAAc,EAAE,kBAAkB,CAAC,CAAC;SAC1C,OAAO,CAAC,kBAAkB,CAAC;IAC9B,WAAW,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,OAAO,CAAC,CAAC,CAAC;IAClC,mBAAmB,EAAE,CAAC,CAAC,OAAO,EAAE,CAAC,OAAO,CAAC,KAAK,CAAC;IAE/C,uBAAuB;IACvB,YAAY,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,OAAO,CAAC,MAAM,CAAC;IAExC,qBAAqB;IACrB,WAAW,EAAE,CAAC,CAAC,KAAK,CAAC,CAAC,CAAC,MAAM,EAAE,CAAC,CAAC,QAAQ,EAAE;IAE3C,0DAA0D;IAC1D,aAAa,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,QAAQ,EAAE;IACpC,SAAS,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,QAAQ,EAAE;IAChC,YAAY,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,QAAQ,EAAE;IACnC,eAAe,EAAE,CAAC,CAAC,OAAO,EAAE,CAAC,OAAO,CAAC,KAAK,CAAC;IAC3C,mBAAmB,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,yBAAyB,CAAC,CAAC,OAAO,CAAC,6BAA6B,CAAC;IACrG,eAAe,EAAE,CAAC,CAAC,IAAI,CAAC,CAAC,aAAa,EAAE,QAAQ,CAAC,CAAC,CAAC,OAAO,CAAC,aAAa,CAAC;IAEzE,sCAAsC;IACtC,SAAS,EAAE,CAAC,CAAC,IAAI,CAAC,CAAC,MAAM,EAAE,KAAK,CAAC,CAAC,CAAC,OAAO,CAAC,MAAM,CAAC;IAClD,cAAc,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,QAAQ,EAAE;IACrC,UAAU,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,QAAQ,EAAE;IACjC,WAAW,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,QAAQ,EAAE,EAAE,yEAAyE;IAC7G,eAAe,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,QAAQ,EAAE;IACtC,kBAAkB,EAAE,CAAC;SAClB,MAAM,CAAC;QACN,GAAG,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC,CAAC,GAAG,CAAC,EAAE,CAAC,CAAC,QAAQ,EAAE;QAC/C,MAAM,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC,CAAC,GAAG,CAAC,GAAG,CAAC,CAAC,QAAQ,EAAE;QACnD,IAAI,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC,CAAC,GAAG,CAAC,GAAG,CAAC,CAAC,QAAQ,EAAE;KAClD,CAAC;SACD,QAAQ,EAAE;IACb,qBAAqB,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,QAAQ,EAAE;IAC5C,yBAAyB,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,QAAQ,EAAE;IAEhD,kBAAkB;IAClB,cAAc,EAAE,CAAC;SACd,MAAM,CAAC;QACN,OAAO,EAAE,CAAC,CAAC,KAAK,CAAC,CAAC,CAAC,MAAM,EAAE,CAAC,CAAC,OAAO,CAAC,CAAC,MAAM,EAAE,YAAY,EAAE,IAAI,CAAC,CAAC;QAClE,SAAS,EAAE,CAAC,CAAC,MAAM,CAAC,CAAC,CAAC,MAAM,EAAE,CAAC,CAAC,QAAQ,EAAE;KAC3C,CAAC;SACD,QAAQ,EAAE;IAEb,yBAAyB;IACzB,cAAc,EAAE,CAAC,CAAC,KAAK,CAAC,mBAAmB,CAAC,CAAC,QAAQ,EAAE;IAEvD,wBAAwB;IACxB,cAAc,EAAE,CAAC;SACd,MAAM,CAAC;QACN,OAAO,EAAE,CAAC,CAAC,IAAI,CAAC,CAAC,UAAU,EAAE,QAAQ,EAAE,MAAM,CAAC,CAAC,CAAC,OAAO,CAAC,UAAU,CAAC;QACnE,MAAM,EAAE,CAAC,CAAC,IAAI,CAAC,CAAC,SAAS,EAAE,SAAS,EAAE,QAAQ,CAAC,CAAC,CAAC,OAAO,CAAC,SAAS,CAAC;QACnE,SAAS,EAAE,CAAC,CAAC,IAAI,CAAC,CAAC,KAAK,EAAE,MAAM,CAAC,CAAC,CAAC,OAAO,CAAC,MAAM,CAAC;KACnD,CAAC;SACD,QAAQ,EAAE;IAEb,yBAAyB;IACzB,QAAQ,EAAE,cAAc,CAAC,QAAQ,EAAE;IAEnC,uBAAuB;IACvB,KAAK,EAAE,WAAW,CAAC,QAAQ,EAAE;IAE7B,4CAA4C;IAC5C,0EAA0E;IAC1E,sCAAsC;IACtC,WAAW,EAAE,iBAAiB,CAAC,QAAQ,EAAE;IAEzC,mCAAmC;IACnC,eAAe,EAAE,CAAC;SACf,IAAI,CAAC,CAAC,MAAM,EAAE,QAAQ,EAAE,OAAO,CAAC,CAAC;SACjC,OAAO,CAAC,MAAM,CAAC;SACf,QAAQ,CACP,mEAAmE;QACjE,sDAAsD,CACzD;IAEH,yBAAyB;IACzB,gBAAgB,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,OAAO,CAAC,iBAAiB,CAAC;IAEvD,2DAA2D;IAC3D,6EAA6E;IAC7E,+EAA+E;IAC/E,wEAAwE;IACxE,iFAAiF;IACjF,OAAO,EAAE,CAAC;SACP,KAAK,CAAC,CAAC,CAAC,CAAC,KAAK,CAAC,CAAC,CAAC,MAAM,EAAE,CAAC,EAAE,CAAC,CAAC,OAAO,CAAC,KAAK,CAAC,CAAC,CAAC;SAC9C,QAAQ,EAAE;IAEb,0EAA0E;IAC1E,yEAAyE;IACzE,8EAA8E;IAC9E,uEAAuE;IACvE,0EAA0E;IAC1E,+EAA+E;IAC/E,4EAA4E;IAC5E,oDAAoD;IACpD,2FAA2F;IAC3F,KAAK,EAAE,CAAC;SACL,MAAM,CAAC;QACN,cAAc,EAAE,CAAC;aACd,MAAM,CAAC;YACN,KAAK,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC,CAAC,QAAQ,EAAE;SACpC,CAAC;aACD,QAAQ,EAAE;QACb,QAAQ,EAAE,CAAC;aACR,MAAM,CAAC;YACN,KAAK,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC,CAAC,QAAQ,EAAE;YACnC,aAAa,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC,CAAC,GAAG,CAAC,EAAE,CAAC,CAAC,QAAQ,EAAE;YACzD,YAAY,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC,CAAC,QAAQ,EAAE;YAChD,YAAY,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC,CAAC,QAAQ,EAAE;SAC3C,CAAC;aACD,QAAQ,EAAE;QACb,MAAM,EAAE,CAAC;aACN,MAAM,CAAC;YACN,KAAK,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC,CAAC,QAAQ,EAAE;SACpC,CAAC;aACD,QAAQ,EAAE;QACb,OAAO,EAAE,CAAC;aACP,MAAM,CAAC;YACN,KAAK,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC,CAAC,QAAQ,EAAE;YACnC,aAAa,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC,CAAC,GAAG,CAAC,EAAE,CAAC,CAAC,QAAQ,EAAE;SAC1D,CAAC;aACD,QAAQ,EAAE;QACb,KAAK,EAAE,CAAC;aACL,MAAM,CAAC;YACN,KAAK,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC,CAAC,QAAQ,EAAE;YACnC,aAAa,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC,CAAC,GAAG,CAAC,EAAE,CAAC,CAAC,QAAQ,EAAE;SAC1D,CAAC;aACD,QAAQ,EAAE;QACb,UAAU,EAAE,CAAC;aACV,MAAM,CAAC;YACN,IAAI,EAAE,CAAC,CAAC,OAAO,EAAE,CAAC,QAAQ,EAAE;SAC7B,CAAC;aACD,QAAQ,EAAE;QACb,aAAa,EAAE,CAAC;aACb,MAAM,CAAC;YACN,KAAK,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC,CAAC,QAAQ,EAAE;SACpC,CAAC;aACD,QAAQ,EAAE;QACb,OAAO,EAAE,CAAC;aACP,MAAM,CAAC;YACN,KAAK,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC,CAAC,QAAQ,EAAE;YACnC,aAAa,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC,CAAC,GAAG,CAAC,EAAE,CAAC,CAAC,QAAQ,EAAE;SAC1D,CAAC;aACD,QAAQ,EAAE;QACb,MAAM,EAAE,CAAC;aACN,MAAM,CAAC;YACN,KAAK,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC,CAAC,QAAQ,EAAE;YACnC,aAAa,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,GAAG,EAAE,CAAC,GAAG,CAAC,CAAC,CAAC,CAAC,GAAG,CAAC,EAAE,CAAC,CAAC,QAAQ,EAAE;YACzD,IAAI,EAAE,CAAC,CAAC,OAAO,EAAE,CAAC,QAAQ,EAAE;SAC7B,CAAC;aACD,QAAQ,EAAE;KACd,CAAC;SACD,QAAQ,EAAE;CACd,CAAC,CAAC;AAGH,wBAAwB;AACxB,MAAM,CAAC,MAAM,cAAc,GAAW;IACpC,aAAa,EAAE,QAAQ;IACvB,SAAS,EAAE,MAAM;IACjB,QAAQ,EAAE,kBAAkB;IAC5B,YAAY,EAAE,8BAA8B;IAC5C,sBAAsB,EAAE,kBAAkB;IAC1C,WAAW,EAAE,CAAC;IACd,mBAAmB,EAAE,KAAK;IAC1B,YAAY,EAAE,MAAM;IACpB,eAAe,EAAE,IAAI;IACrB,mBAAmB,EAAE,6BAA6B;IAClD,eAAe,EAAE,aAAa;IAC9B,eAAe,EAAE,MAAM;IACvB,gBAAgB,EAAE,iBAAiB;CACpC,CAAC"}
|