@aperant/framework 0.12.0 → 0.12.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/CHANGELOG.md
CHANGED
|
@@ -3,6 +3,20 @@
|
|
|
3
3
|
All notable changes to `@aperant/framework` are documented here. See
|
|
4
4
|
[`VERSIONING.md`](VERSIONING.md) for the per-tier contract.
|
|
5
5
|
|
|
6
|
+
## 0.12.1 — 2026-06-03 — Fix: `/apt` router honors per-track orchestration
|
|
7
|
+
|
|
8
|
+
### Fixed
|
|
9
|
+
|
|
10
|
+
- **`/apt` router no longer over-delegates STANDARD tasks.** The router's
|
|
11
|
+
capability-based-spawning rule resolved the orchestration mode with a bare
|
|
12
|
+
`reconcile .`, dropping the task's track. A STANDARD task whose configured
|
|
13
|
+
mode is `orchestration.per_track.standard = "sequential"` therefore resolved
|
|
14
|
+
to the host's most-capable mode (e.g. `agent-team`) and over-delegated — even
|
|
15
|
+
though `/apt:run` (which passes `--track`) ran the same task inline. The
|
|
16
|
+
router now passes `reconcile . --track {track}`, so per-track defaults apply
|
|
17
|
+
on both entry paths. Adds a prompt-contract guard test
|
|
18
|
+
(`apt-router-reconcile-track.test.ts`) pinning the `--track` invocation. (#299)
|
|
19
|
+
|
|
6
20
|
## 0.12.0 — 2026-05-31 — Mobile verification surface for verify-proof (iOS + Android)
|
|
7
21
|
|
|
8
22
|
Adds a mobile verification surface so `/apt:verify-proof` can drive native
|
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "aperant",
|
|
3
|
-
"version": "0.12.
|
|
3
|
+
"version": "0.12.1",
|
|
4
4
|
"description": "AI coding framework — composable skills for planning, executing, verifying, and reviewing code with any LLM provider. Works as Claude Code commands, Codex tasks, or programmatically.",
|
|
5
5
|
"author": {
|
|
6
6
|
"name": "Mikalsen AI",
|
|
@@ -687,10 +687,10 @@ When spawning agents, follow these rules:
|
|
|
687
687
|
3. **Agent type from route result.** The `agent` field in the route JSON tells you which agent to spawn.
|
|
688
688
|
4. **Model selection:** Use `sonnet` for agents unless the task is complex (DEEP track), then use the default model.
|
|
689
689
|
5. **Always include task_dir.** Every agent needs to know where to read/write artifacts.
|
|
690
|
-
6. **Capability-based spawning:** Before spawning agents for task mode (execution_mode = "auto"), check the reconciled orchestration mode:
|
|
690
|
+
6. **Capability-based spawning:** Before spawning agents for task mode (execution_mode = "auto"), check the reconciled orchestration mode. Pass the task's `{track}` (from Step 0c) via `--track` so per-track defaults from `.aperant/config.json:orchestration.per_track` apply — without it, a STANDARD task whose configured mode is `sequential` silently resolves to the host's most-capable mode (e.g. `agent-team`) and over-delegates:
|
|
691
691
|
|
|
692
692
|
```bash
|
|
693
|
-
node packages/framework/bin/apt-tools.mjs reconcile .
|
|
693
|
+
node packages/framework/bin/apt-tools.mjs reconcile . --track {track}
|
|
694
694
|
```
|
|
695
695
|
|
|
696
696
|
Use `resolved.phase_delegation` to decide how agents are launched:
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@aperant/framework",
|
|
3
|
-
"version": "0.12.
|
|
3
|
+
"version": "0.12.1",
|
|
4
4
|
"description": "AI coding framework — composable skills for planning, executing, verifying, and reviewing code with any LLM provider. Works as Claude Code commands, Codex tasks, or programmatically.",
|
|
5
5
|
"author": "Mikalsen AI <hello@mikalsen.ai>",
|
|
6
6
|
"type": "module",
|
|
@@ -8,4 +8,10 @@ Otherwise, populate nextChatMessage with EXACTLY ONE focused, concrete question
|
|
|
8
8
|
Ground the question in the triage findings, the inbox title and description, and the prior message history. Acknowledge what the user already said when relevant.
|
|
9
9
|
Set nextChatMessage.dimensionKey to the readiness dimension the question targets, and nextChatMessage.cardId to the matching open clarification card when one exists.
|
|
10
10
|
Keep nextClarificationQuestions as the ordered list of remaining open questions (one per open dimension); the UI renders this list as a chip row alongside the chat.
|
|
11
|
+
If the user's prior answer did not raise the targeted dimension's readinessAssessment score above its scoreThreshold, the next question MUST target the same dimensionKey with a sharper or more concrete follow-up. Otherwise, advance to a different open dimension.
|
|
12
|
+
Target the gating dimension whose acceptance-criteria slots are still open; do not jump to a dimension whose slots are already grounded.
|
|
13
|
+
Emit proposedAcceptanceCriteriaUpdates as field-level patches ({ acIndex, fieldPath, value, source, groundedness }) that fill the targeted acceptance-criteria slots from the user's answer; fieldPath is one of statement, given, when, thenOutcome, verificationMethod.
|
|
14
|
+
Mark a slot patch groundedness:'tentative' when you are filling it from a vague answer or your own assumption, and groundedness:'grounded' only when the user's answer concretely specifies the field.
|
|
15
|
+
On an explicit not_applicable reply, do not write a value; on an explicit agent_assume reply, fill the slot with source:'agent_assume'. Otherwise use source:'user_answer'.
|
|
16
|
+
Ask EXACTLY ONE question per turn, and do not re-grill the same dimension more than three turns.
|
|
11
17
|
Use repository tools only when needed to sharpen the question.
|
package/prompts/inbox-triage.md
CHANGED
|
@@ -17,4 +17,5 @@ Only place verified repository findings in repoEvidencedFacts.
|
|
|
17
17
|
For every inferred assumption, set disposition to requires_hitl_confirmation or accepted_assumption.
|
|
18
18
|
Do not present product commitments as facts unless repository evidence directly supports them.
|
|
19
19
|
Each proposed acceptance criterion must include a verificationMethod and Given/When/Then fields when behavior is being specified.
|
|
20
|
+
Tag each proposed acceptance criterion with the readiness dimensionKey it supports (one of the universal or type-specific readiness keys listed above) so the clarification gate can map each acceptance criterion to its dimension exactly.
|
|
20
21
|
Prefer concise summaries and concrete touch points.
|
package/skills/apt/SKILL.md
CHANGED
|
@@ -687,10 +687,10 @@ When spawning agents, follow these rules:
|
|
|
687
687
|
3. **Agent type from route result.** The `agent` field in the route JSON tells you which agent to spawn.
|
|
688
688
|
4. **Model selection:** Use `sonnet` for agents unless the task is complex (DEEP track), then use the default model.
|
|
689
689
|
5. **Always include task_dir.** Every agent needs to know where to read/write artifacts.
|
|
690
|
-
6. **Capability-based spawning:** Before spawning agents for task mode (execution_mode = "auto"), check the reconciled orchestration mode:
|
|
690
|
+
6. **Capability-based spawning:** Before spawning agents for task mode (execution_mode = "auto"), check the reconciled orchestration mode. Pass the task's `{track}` (from Step 0c) via `--track` so per-track defaults from `.aperant/config.json:orchestration.per_track` apply — without it, a STANDARD task whose configured mode is `sequential` silently resolves to the host's most-capable mode (e.g. `agent-team`) and over-delegates:
|
|
691
691
|
|
|
692
692
|
```bash
|
|
693
|
-
node packages/framework/bin/apt-tools.mjs reconcile .
|
|
693
|
+
node packages/framework/bin/apt-tools.mjs reconcile . --track {track}
|
|
694
694
|
```
|
|
695
695
|
|
|
696
696
|
Use `resolved.phase_delegation` to decide how agents are launched:
|