@codename_inc/spectre 5.2.0 → 5.2.1
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: plan_review
|
|
3
|
-
description: 👻 | Independent multi-lens review of plan.md
|
|
3
|
+
description: 👻 | Independent multi-lens review of plan.md and/or tasks.md — finds overengineering, missing verification, hallucinated deps, weak references
|
|
4
4
|
user-invocable: true
|
|
5
5
|
---
|
|
6
6
|
|
|
@@ -10,12 +10,12 @@ user-invocable: true
|
|
|
10
10
|
|
|
11
11
|
Treat the current command arguments as this workflow's input. When invoked from a slash command, use the forwarded `$ARGUMENTS` value.
|
|
12
12
|
|
|
13
|
-
# plan_review: Multi-Lens Review of Plan
|
|
13
|
+
# plan_review: Multi-Lens Review of Plan and/or Tasks
|
|
14
14
|
|
|
15
15
|
## Description
|
|
16
16
|
|
|
17
|
-
- **What** — Independent review of `plan.md`
|
|
18
|
-
- **Outcome** — Structured findings with concrete edit suggestions; optional write-back to update
|
|
17
|
+
- **What** — Independent review of any available planning artifacts (`plan.md`, `tasks.md`, and optional `task_context.md`) from four specialized lenses, dispatched in parallel
|
|
18
|
+
- **Outcome** — Structured findings with concrete edit suggestions; optional write-back to update the available artifacts
|
|
19
19
|
- **Role** — Senior staff engineer + reviewer panel; bias toward pragmatic problem-solving, YAGNI enforcement, and verifiability
|
|
20
20
|
|
|
21
21
|
## ARGUMENTS Input
|
|
@@ -42,25 +42,30 @@ A single reviewer biases toward the issues it notices first. Published practice
|
|
|
42
42
|
- **If** user specifies path in ARGUMENTS → `TASK_DIR={that value}`
|
|
43
43
|
- **Else** → `TASK_DIR=docs/tasks/{branch_name}`
|
|
44
44
|
|
|
45
|
-
- **Action** — ResolveArtifacts: Locate the
|
|
45
|
+
- **Action** — ResolveArtifacts: Locate the available review inputs.
|
|
46
46
|
- `PLAN=${TASK_DIR}/specs/plan.md` (or scoped name)
|
|
47
47
|
- `TASKS=${TASK_DIR}/specs/tasks.md` (or scoped name)
|
|
48
48
|
- `CONTEXT=${TASK_DIR}/task_context.md`
|
|
49
|
-
-
|
|
49
|
+
- `plan.md` and `tasks.md` are independently reviewable. It is valid to review only `plan.md`, only `tasks.md`, or both.
|
|
50
|
+
- `task_context.md` is helpful context but is not required. If it is missing, continue and note that requirements traceability is limited.
|
|
51
|
+
- If both `plan.md` and `tasks.md` are missing, stop and suggest the user run `/spectre:plan` or `/spectre:create_tasks` first.
|
|
52
|
+
- If exactly one of `plan.md` or `tasks.md` is missing, list it as absent context and continue. Do not decline, stop, or ask the user to create the missing artifact.
|
|
50
53
|
|
|
51
|
-
- **Action** —
|
|
54
|
+
- **Action** — ReadAvailable: Read each available file completely into context before dispatching reviewers. Reviewers receive curated excerpts plus an artifact manifest that says which files are present and absent. Every reviewer must review the artifacts that exist and must not treat absent artifacts as a blocker.
|
|
52
55
|
|
|
53
56
|
## Step 2 — Dispatch Four Parallel Reviewers
|
|
54
57
|
|
|
55
|
-
Spawn all four subagents in a single message (parallel). Each receives the same artifact excerpts
|
|
58
|
+
Spawn all four subagents in a single message (parallel). Each receives the same available artifact excerpts, the artifact manifest, and a different review brief.
|
|
59
|
+
|
|
60
|
+
Missing-artifact rule for every lens: review what exists. If a finding depends on a missing artifact, phrase it as "not reviewable because `<artifact>` is absent" only when that context is necessary; do not fail the review or ask for the missing artifact.
|
|
56
61
|
|
|
57
62
|
### Lens 1 — YAGNI / Familiar-Shape Bias (`@reviewer`)
|
|
58
63
|
|
|
59
|
-
> Review
|
|
64
|
+
> Review the available plan and/or task list for unrequested complexity. Agents have a documented "familiar-shape bias": shown a feature, they reproduce the mature-system shape from their training data (auth → adds rate-limiting; CRUD → adds soft-delete; form → adds optimistic UI; service → adds telemetry; module → adds feature flags). Your job is to find that bias here.
|
|
60
65
|
>
|
|
61
66
|
> Find:
|
|
62
|
-
> 1.
|
|
63
|
-
> 2.
|
|
67
|
+
> 1. When `plan.md` is present: anything in Technical Approach that isn't traceable to a requirement in available context (`task_context.md` / scope / PRD). If context is absent, use the plan's own requirements and boundaries.
|
|
68
|
+
> 2. When `tasks.md` is present: tasks that implement something the available requirements don't ask for. If requirements context is absent, use the task list's stated goals and boundaries.
|
|
64
69
|
> 3. Abstractions, interfaces, or layers introduced for a single concrete caller.
|
|
65
70
|
> 4. Generality (config files, plugin points, factories) where the actual need is one specific behavior.
|
|
66
71
|
> 5. Overlap with the `Out-of-Bounds — DO NOT add` list (if anything violates that list, it's a hard fail).
|
|
@@ -69,36 +74,36 @@ Spawn all four subagents in a single message (parallel). Each receives the same
|
|
|
69
74
|
|
|
70
75
|
### Lens 2 — Verifiability (`@analyst`)
|
|
71
76
|
|
|
72
|
-
> Review
|
|
77
|
+
> Review the available plan and/or task list for verification quality. The single highest-correlate of successful AI-agent execution is the ability to self-verify. Find every place where verification is missing, prose-only, or disconnected.
|
|
73
78
|
>
|
|
74
79
|
> Find:
|
|
75
|
-
> 1.
|
|
76
|
-
> 2.
|
|
77
|
-
> 3.
|
|
78
|
-
> 4.
|
|
79
|
-
> 5.
|
|
80
|
+
> 1. When `plan.md` is present: items in "Verification — How We Know This Works" that are prose ("works correctly", "is consistent") rather than executable (test name / observable behavior / state condition).
|
|
81
|
+
> 2. When `plan.md` is present: phases that don't declare a verification signal.
|
|
82
|
+
> 3. When `tasks.md` is present: sub-tasks whose acceptance criteria aren't one of the three executable types (test passes / observable behavior / state condition).
|
|
83
|
+
> 4. When both `plan.md` and `tasks.md` are present: verification signals in `plan.md` with no matching acceptance criterion in `tasks.md`.
|
|
84
|
+
> 5. When `tasks.md` is present: behavior-changing sub-tasks that lack a preceding RED test sub-task.
|
|
80
85
|
>
|
|
81
86
|
> Required output: list every non-executable criterion with a proposed rewrite in one of the three types. Cite file:line for each.
|
|
82
87
|
|
|
83
88
|
### Lens 3 — Existence / Hallucination (`@finder`)
|
|
84
89
|
|
|
85
|
-
> Review
|
|
90
|
+
> Review the available plan and/or task list for references to things that may not exist. AI-generated plans hallucinate file paths, package names, function signatures, and API endpoints at measurable rates (~20% for packages per Snyk analysis). Your job is to verify every reference is real.
|
|
86
91
|
>
|
|
87
92
|
> Verify:
|
|
88
|
-
> 1. Every file path mentioned in `plan.md` "Critical Files for Implementation" and
|
|
89
|
-
> 2. Every package in `plan.md` "External Dependencies" — does it exist at the named version? (Note: actual install/registry check is the executor's Phase 0 job; your job is to flag suspicious names — typos, near-misses to well-known packages, lookalikes.)
|
|
90
|
-
> 3. Every function, class, or symbol named in plan/tasks — grep the repo, confirm it exists where claimed.
|
|
93
|
+
> 1. Every file path mentioned in available artifacts, including `plan.md` "Critical Files for Implementation" and `tasks.md` Context blocks when present — does the file exist in the repo today? Use Glob/Read to confirm.
|
|
94
|
+
> 2. Every package in `plan.md` "External Dependencies" when `plan.md` is present — does it exist at the named version? (Note: actual install/registry check is the executor's Phase 0 job; your job is to flag suspicious names — typos, near-misses to well-known packages, lookalikes.)
|
|
95
|
+
> 3. Every function, class, or symbol named in available plan/tasks — grep the repo, confirm it exists where claimed.
|
|
91
96
|
> 4. Every API endpoint, env var, or CLI flag referenced — confirm it's defined in the codebase.
|
|
92
97
|
>
|
|
93
98
|
> Required output: list every reference that fails verification, with `expected: <plan claim>` and `actual: <repo state>`. If everything checks out, say so explicitly — don't pad.
|
|
94
99
|
|
|
95
100
|
### Lens 4 — Canonical Reference Quality (`@patterns`)
|
|
96
101
|
|
|
97
|
-
> Review
|
|
102
|
+
> Review the available plan and/or task list for the quality of "follow existing pattern" references. Anthropic's own guidance is to anchor plans with concrete examples (e.g., "HotDogWidget.php is a good example"). Vague "follow existing patterns" without a file:line anchor is a documented failure mode.
|
|
98
103
|
>
|
|
99
104
|
> Find:
|
|
100
|
-
> 1.
|
|
101
|
-
> 2.
|
|
105
|
+
> 1. When `plan.md` is present: places in Technical Approach that reference "existing patterns" or "similar features" without a specific file:line.
|
|
106
|
+
> 2. When `tasks.md` is present: sub-tasks whose Context block lacks a canonical reference pointer.
|
|
102
107
|
> 3. Better canonical references that the plan missed — actual files in the codebase that more closely match the intended shape.
|
|
103
108
|
> 4. Reuse opportunities the plan ignored: utilities, hooks, helpers, or types already in the repo that the plan re-implements.
|
|
104
109
|
>
|
|
@@ -150,12 +155,12 @@ Spawn all four subagents in a single message (parallel). Each receives the same
|
|
|
150
155
|
> - `1,3,5` — apply specific finding numbers
|
|
151
156
|
> - `skip` — leave artifacts unchanged
|
|
152
157
|
>
|
|
153
|
-
> For findings I apply, I'll edit
|
|
158
|
+
> For findings I apply, I'll edit the relevant available artifact(s) inline and re-run a fast self-check.
|
|
154
159
|
|
|
155
160
|
- **Wait** — User selects.
|
|
156
161
|
|
|
157
162
|
- **Action** — ApplyEdits: For each selected finding:
|
|
158
|
-
- Open the named artifact (plan.md or tasks.md)
|
|
163
|
+
- Open the named artifact (`plan.md` or `tasks.md`)
|
|
159
164
|
- Apply the Suggested Edit verbatim where possible; if the edit needs adaptation, make the minimum change consistent with the finding's intent
|
|
160
165
|
- Track which findings were applied
|
|
161
166
|
|
|
@@ -168,7 +173,7 @@ Spawn all four subagents in a single message (parallel). Each receives the same
|
|
|
168
173
|
- **Action** — ReportApplied:
|
|
169
174
|
|
|
170
175
|
> Applied: {list of finding numbers}. Skipped: {list}.
|
|
171
|
-
> {Path to updated
|
|
176
|
+
> {Path to updated artifact(s)}.
|
|
172
177
|
|
|
173
178
|
## Step 5 — Next Steps
|
|
174
179
|
|
|
@@ -178,6 +183,6 @@ Spawn all four subagents in a single message (parallel). Each receives the same
|
|
|
178
183
|
|
|
179
184
|
## Notes
|
|
180
185
|
|
|
181
|
-
- This skill does NOT generate plans or tasks. It reviews
|
|
186
|
+
- This skill does NOT generate plans or tasks. It reviews available planning artifacts. If only one of `plan.md` or `tasks.md` exists, review that artifact. Only route the user to `/spectre:plan` or `/spectre:create_tasks` when neither reviewable artifact exists.
|
|
182
187
|
- The four lenses are intentionally non-overlapping by design but will surface overlap in practice — dedupe at synthesis, don't ask reviewers to coordinate.
|
|
183
188
|
- The "Must-Delete" nomination from Lens 1 is mandatory output — even on a tight plan, naming the single weakest element is a forcing function against under-review.
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
---
|
|
2
2
|
name: "plan_review"
|
|
3
|
-
description: "👻 | Independent multi-lens review of plan.md
|
|
3
|
+
description: "👻 | Independent multi-lens review of plan.md and/or tasks.md — finds overengineering, missing verification, hallucinated deps, weak references"
|
|
4
4
|
user-invocable: true
|
|
5
5
|
---
|
|
6
6
|
|
|
@@ -10,12 +10,12 @@ user-invocable: true
|
|
|
10
10
|
|
|
11
11
|
Treat the current command arguments as this workflow's input. When invoked from a slash command, use the forwarded `$ARGUMENTS` value.
|
|
12
12
|
|
|
13
|
-
# plan_review: Multi-Lens Review of Plan
|
|
13
|
+
# plan_review: Multi-Lens Review of Plan and/or Tasks
|
|
14
14
|
|
|
15
15
|
## Description
|
|
16
16
|
|
|
17
|
-
- **What** — Independent review of `plan.md`
|
|
18
|
-
- **Outcome** — Structured findings with concrete edit suggestions; optional write-back to update
|
|
17
|
+
- **What** — Independent review of any available planning artifacts (`plan.md`, `tasks.md`, and optional `task_context.md`) from four specialized lenses, dispatched in parallel
|
|
18
|
+
- **Outcome** — Structured findings with concrete edit suggestions; optional write-back to update the available artifacts
|
|
19
19
|
- **Role** — Senior staff engineer + reviewer panel; bias toward pragmatic problem-solving, YAGNI enforcement, and verifiability
|
|
20
20
|
|
|
21
21
|
## ARGUMENTS Input
|
|
@@ -42,25 +42,30 @@ A single reviewer biases toward the issues it notices first. Published practice
|
|
|
42
42
|
- **If** user specifies path in ARGUMENTS → `TASK_DIR={that value}`
|
|
43
43
|
- **Else** → `TASK_DIR=docs/tasks/{branch_name}`
|
|
44
44
|
|
|
45
|
-
- **Action** — ResolveArtifacts: Locate the
|
|
45
|
+
- **Action** — ResolveArtifacts: Locate the available review inputs.
|
|
46
46
|
- `PLAN=${TASK_DIR}/specs/plan.md` (or scoped name)
|
|
47
47
|
- `TASKS=${TASK_DIR}/specs/tasks.md` (or scoped name)
|
|
48
48
|
- `CONTEXT=${TASK_DIR}/task_context.md`
|
|
49
|
-
-
|
|
49
|
+
- `plan.md` and `tasks.md` are independently reviewable. It is valid to review only `plan.md`, only `tasks.md`, or both.
|
|
50
|
+
- `task_context.md` is helpful context but is not required. If it is missing, continue and note that requirements traceability is limited.
|
|
51
|
+
- If both `plan.md` and `tasks.md` are missing, stop and suggest the user run `plan` or `create_tasks` first.
|
|
52
|
+
- If exactly one of `plan.md` or `tasks.md` is missing, list it as absent context and continue. Do not decline, stop, or ask the user to create the missing artifact.
|
|
50
53
|
|
|
51
|
-
- **Action** —
|
|
54
|
+
- **Action** — ReadAvailable: Read each available file completely into context before dispatching reviewers. Reviewers receive curated excerpts plus an artifact manifest that says which files are present and absent. Every reviewer must review the artifacts that exist and must not treat absent artifacts as a blocker.
|
|
52
55
|
|
|
53
56
|
## Step 2 — Dispatch Four Parallel Reviewers
|
|
54
57
|
|
|
55
|
-
Spawn all four subagents in a single message (parallel). Each receives the same artifact excerpts
|
|
58
|
+
Spawn all four subagents in a single message (parallel). Each receives the same available artifact excerpts, the artifact manifest, and a different review brief.
|
|
59
|
+
|
|
60
|
+
Missing-artifact rule for every lens: review what exists. If a finding depends on a missing artifact, phrase it as "not reviewable because `<artifact>` is absent" only when that context is necessary; do not fail the review or ask for the missing artifact.
|
|
56
61
|
|
|
57
62
|
### Lens 1 — YAGNI / Familiar-Shape Bias (`@reviewer`)
|
|
58
63
|
|
|
59
|
-
> Review
|
|
64
|
+
> Review the available plan and/or task list for unrequested complexity. Agents have a documented "familiar-shape bias": shown a feature, they reproduce the mature-system shape from their training data (auth → adds rate-limiting; CRUD → adds soft-delete; form → adds optimistic UI; service → adds telemetry; module → adds feature flags). Your job is to find that bias here.
|
|
60
65
|
>
|
|
61
66
|
> Find:
|
|
62
|
-
> 1.
|
|
63
|
-
> 2.
|
|
67
|
+
> 1. When `plan.md` is present: anything in Technical Approach that isn't traceable to a requirement in available context (`task_context.md` / scope / PRD). If context is absent, use the plan's own requirements and boundaries.
|
|
68
|
+
> 2. When `tasks.md` is present: tasks that implement something the available requirements don't ask for. If requirements context is absent, use the task list's stated goals and boundaries.
|
|
64
69
|
> 3. Abstractions, interfaces, or layers introduced for a single concrete caller.
|
|
65
70
|
> 4. Generality (config files, plugin points, factories) where the actual need is one specific behavior.
|
|
66
71
|
> 5. Overlap with the `Out-of-Bounds — DO NOT add` list (if anything violates that list, it's a hard fail).
|
|
@@ -69,36 +74,36 @@ Spawn all four subagents in a single message (parallel). Each receives the same
|
|
|
69
74
|
|
|
70
75
|
### Lens 2 — Verifiability (`@analyst`)
|
|
71
76
|
|
|
72
|
-
> Review
|
|
77
|
+
> Review the available plan and/or task list for verification quality. The single highest-correlate of successful AI-agent execution is the ability to self-verify. Find every place where verification is missing, prose-only, or disconnected.
|
|
73
78
|
>
|
|
74
79
|
> Find:
|
|
75
|
-
> 1.
|
|
76
|
-
> 2.
|
|
77
|
-
> 3.
|
|
78
|
-
> 4.
|
|
79
|
-
> 5.
|
|
80
|
+
> 1. When `plan.md` is present: items in "Verification — How We Know This Works" that are prose ("works correctly", "is consistent") rather than executable (test name / observable behavior / state condition).
|
|
81
|
+
> 2. When `plan.md` is present: phases that don't declare a verification signal.
|
|
82
|
+
> 3. When `tasks.md` is present: sub-tasks whose acceptance criteria aren't one of the three executable types (test passes / observable behavior / state condition).
|
|
83
|
+
> 4. When both `plan.md` and `tasks.md` are present: verification signals in `plan.md` with no matching acceptance criterion in `tasks.md`.
|
|
84
|
+
> 5. When `tasks.md` is present: behavior-changing sub-tasks that lack a preceding RED test sub-task.
|
|
80
85
|
>
|
|
81
86
|
> Required output: list every non-executable criterion with a proposed rewrite in one of the three types. Cite file:line for each.
|
|
82
87
|
|
|
83
88
|
### Lens 3 — Existence / Hallucination (`@finder`)
|
|
84
89
|
|
|
85
|
-
> Review
|
|
90
|
+
> Review the available plan and/or task list for references to things that may not exist. AI-generated plans hallucinate file paths, package names, function signatures, and API endpoints at measurable rates (~20% for packages per Snyk analysis). Your job is to verify every reference is real.
|
|
86
91
|
>
|
|
87
92
|
> Verify:
|
|
88
|
-
> 1. Every file path mentioned in `plan.md` "Critical Files for Implementation" and
|
|
89
|
-
> 2. Every package in `plan.md` "External Dependencies" — does it exist at the named version? (Note: actual install/registry check is the executor's Phase 0 job; your job is to flag suspicious names — typos, near-misses to well-known packages, lookalikes.)
|
|
90
|
-
> 3. Every function, class, or symbol named in plan/tasks — grep the repo, confirm it exists where claimed.
|
|
93
|
+
> 1. Every file path mentioned in available artifacts, including `plan.md` "Critical Files for Implementation" and `tasks.md` Context blocks when present — does the file exist in the repo today? Use Glob/Read to confirm.
|
|
94
|
+
> 2. Every package in `plan.md` "External Dependencies" when `plan.md` is present — does it exist at the named version? (Note: actual install/registry check is the executor's Phase 0 job; your job is to flag suspicious names — typos, near-misses to well-known packages, lookalikes.)
|
|
95
|
+
> 3. Every function, class, or symbol named in available plan/tasks — grep the repo, confirm it exists where claimed.
|
|
91
96
|
> 4. Every API endpoint, env var, or CLI flag referenced — confirm it's defined in the codebase.
|
|
92
97
|
>
|
|
93
98
|
> Required output: list every reference that fails verification, with `expected: <plan claim>` and `actual: <repo state>`. If everything checks out, say so explicitly — don't pad.
|
|
94
99
|
|
|
95
100
|
### Lens 4 — Canonical Reference Quality (`@patterns`)
|
|
96
101
|
|
|
97
|
-
> Review
|
|
102
|
+
> Review the available plan and/or task list for the quality of "follow existing pattern" references. Anthropic's own guidance is to anchor plans with concrete examples (e.g., "HotDogWidget.php is a good example"). Vague "follow existing patterns" without a file:line anchor is a documented failure mode.
|
|
98
103
|
>
|
|
99
104
|
> Find:
|
|
100
|
-
> 1.
|
|
101
|
-
> 2.
|
|
105
|
+
> 1. When `plan.md` is present: places in Technical Approach that reference "existing patterns" or "similar features" without a specific file:line.
|
|
106
|
+
> 2. When `tasks.md` is present: sub-tasks whose Context block lacks a canonical reference pointer.
|
|
102
107
|
> 3. Better canonical references that the plan missed — actual files in the codebase that more closely match the intended shape.
|
|
103
108
|
> 4. Reuse opportunities the plan ignored: utilities, hooks, helpers, or types already in the repo that the plan re-implements.
|
|
104
109
|
>
|
|
@@ -150,12 +155,12 @@ Spawn all four subagents in a single message (parallel). Each receives the same
|
|
|
150
155
|
> - `1,3,5` — apply specific finding numbers
|
|
151
156
|
> - `skip` — leave artifacts unchanged
|
|
152
157
|
>
|
|
153
|
-
> For findings I apply, I'll edit
|
|
158
|
+
> For findings I apply, I'll edit the relevant available artifact(s) inline and re-run a fast self-check.
|
|
154
159
|
|
|
155
160
|
- **Wait** — User selects.
|
|
156
161
|
|
|
157
162
|
- **Action** — ApplyEdits: For each selected finding:
|
|
158
|
-
- Open the named artifact (plan.md or tasks.md)
|
|
163
|
+
- Open the named artifact (`plan.md` or `tasks.md`)
|
|
159
164
|
- Apply the Suggested Edit verbatim where possible; if the edit needs adaptation, make the minimum change consistent with the finding's intent
|
|
160
165
|
- Track which findings were applied
|
|
161
166
|
|
|
@@ -168,7 +173,7 @@ Spawn all four subagents in a single message (parallel). Each receives the same
|
|
|
168
173
|
- **Action** — ReportApplied:
|
|
169
174
|
|
|
170
175
|
> Applied: {list of finding numbers}. Skipped: {list}.
|
|
171
|
-
> {Path to updated
|
|
176
|
+
> {Path to updated artifact(s)}.
|
|
172
177
|
|
|
173
178
|
## Step 5 — Next Steps
|
|
174
179
|
|
|
@@ -178,6 +183,6 @@ Spawn all four subagents in a single message (parallel). Each receives the same
|
|
|
178
183
|
|
|
179
184
|
## Notes
|
|
180
185
|
|
|
181
|
-
- This skill does NOT generate plans or tasks. It reviews
|
|
186
|
+
- This skill does NOT generate plans or tasks. It reviews available planning artifacts. If only one of `plan.md` or `tasks.md` exists, review that artifact. Only route the user to `plan` or `create_tasks` when neither reviewable artifact exists.
|
|
182
187
|
- The four lenses are intentionally non-overlapping by design but will surface overlap in practice — dedupe at synthesis, don't ask reviewers to coordinate.
|
|
183
188
|
- The "Must-Delete" nomination from Lens 1 is mandatory output — even on a tight plan, naming the single weakest element is a forcing function against under-review.
|