mirror of
https://github.com/affaan-m/ECC.git
synced 2026-08-24 00:12:25 +02:00
754b8dd76c
* fix: make the installer runtime pass strict supply-chain vetting
Remediate the four enterprise supply-chain vetting blockers from
affaan-m/ECC#2502 so the installer runtime (package.json + manifests +
scripts/lib/**) passes strict exact-pin evidence policy:
1. Remove the package.json `postinstall` lifecycle script (it only echoed a
post-install banner) and move that banner to an explicit opt-in
`npm run welcome` command. No install-time lifecycle script remains.
2. Exact-pin every dependency in package.json (dependencies + devDependencies)
to the versions already resolved in package-lock.json; no ^/~ ranges.
3. Replace non-ASCII characters on the installer runtime script/config surface:
em-dashes (U+2014) in scripts/lib/{path-safety,install-executor,
install/link-rewrite}.js comments and the two "Itô" (U+00F4) occurrences in
manifests/{install-components,install-modules}.json descriptions become
ASCII, so strict-surface Unicode scanners are clean.
4. Drop the bare `require("ajv")` from scripts/lib/install-state.js; the file
already carries a complete hand-rolled validator enforcing the same
schemas/install-state.schema.json (ecc.install.v1) constraints, so the
installer closure is dependency-free (zero non-builtin bare requires).
Refs affaan-m/ECC#2502
* fix: avoid unpinned welcome invocations
Signed-off-by: Samar Tomar <samar_tomar@hotmail.com>
* fix: validate translated skill frontmatter
Signed-off-by: Samar Tomar <samar_tomar@hotmail.com>
* fix: repair skill frontmatter YAML
Signed-off-by: Samar Tomar <samar_tomar@hotmail.com>
* fix: add MIT license to core skill manifests; pin verification-loop tsc invocation
* fix: preserve tsc/pyright exit status in verification-loop type-check (set -o pipefail)
* chore(deps): sync lockfiles with exact-pinned package.json
Regenerate package-lock.json and yarn.lock so the pinned dependency
specs are reflected in both lockfiles. npm ci and Yarn's --immutable
install now pass the sync check. The resolution tree is unchanged
(231 yarn resolutions, byte-identical set; zero npm transitive drift);
only the root descriptor strings move from ranges to the versions
already resolved in the committed lockfiles.
Addresses the Codex P1 on #2503.
---------
Signed-off-by: Samar Tomar <samar_tomar@hotmail.com>
Co-authored-by: Samarjeet Singh Tomar <samartomar@gmail.com>
75 lines
2.6 KiB
Markdown
75 lines
2.6 KiB
Markdown
---
|
|
name: parallel-execution-optimizer
|
|
description: Use when the user wants a task done much faster through parallel work, concurrent agents, batched tool calls, isolated worktrees, or many independent verification lanes without losing correctness.
|
|
license: MIT
|
|
metadata:
|
|
origin: ECC
|
|
tools: Read, Write, Edit, Bash, Grep, Glob
|
|
---
|
|
|
|
# Parallel Execution Optimizer
|
|
|
|
Use this skill when speed comes from doing independent work at the same time:
|
|
repo inspection, file reads, API checks, browser checks, build/test lanes,
|
|
deploy readbacks, or multi-worktree implementation passes.
|
|
|
|
## Core Pattern
|
|
|
|
Turn urgency into a dependency graph before acting.
|
|
|
|
1. Define the objective and done signal.
|
|
2. Split work into lanes.
|
|
3. Mark each lane as parallel, sequential, or gated.
|
|
4. Run independent reads/checks together.
|
|
5. Keep writes isolated by file, worktree, branch, service, or dataset.
|
|
6. Merge only after evidence shows the lanes are compatible.
|
|
7. End with a verification table, not a vague speed claim.
|
|
|
|
## Lane Matrix
|
|
|
|
Before a large push, write a compact matrix:
|
|
|
|
```text
|
|
Lane | Can run in parallel? | Write surface | Risk | Verification
|
|
Repo scan | yes | none | low | rg/git status outputs
|
|
Backend patch | maybe | src/api | medium | unit tests
|
|
Frontend patch | maybe | app/components | medium | browser screenshot
|
|
Deploy readback | after build | remote service | high | live URL + logs
|
|
```
|
|
|
|
Only run lanes in parallel when their write surfaces do not collide.
|
|
|
|
## Execution Rules
|
|
|
|
- Batch file reads, searches, status checks, and metadata queries.
|
|
- Use isolated worktrees for large unrelated implementation lanes.
|
|
- Start long-running tests, builds, backfills, and deploys in separate sessions,
|
|
then poll them deliberately.
|
|
- If a lane discovers a blocker that changes the plan, pause dependent lanes
|
|
and update the matrix.
|
|
- Never let a background process outlive the turn unless the user explicitly
|
|
asked for a continuing service.
|
|
- Do not parallelize destructive commands, migrations, writes to the same table,
|
|
or live customer-impacting deploys without an explicit gate.
|
|
|
|
## Output Shape
|
|
|
|
Use this when reporting:
|
|
|
|
```text
|
|
Parallel execution result:
|
|
- Lanes run: 5
|
|
- Lanes completed: 4
|
|
- Blocked lane: deploy readback, waiting on DNS propagation
|
|
- Fast path found: batched repo scan + focused tests
|
|
- Verification: lint pass, unit pass, live smoke pass
|
|
```
|
|
|
|
## Failure Modes
|
|
|
|
- More concurrency that creates conflicting edits.
|
|
- Benchmarking the tool instead of the task.
|
|
- Treating "fast" as done before correctness is proven.
|
|
- Forgetting to poll running sessions.
|
|
- Hiding skipped checks behind a success summary.
|