axstack 0.58.0 → 0.59.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "axstack",
-  "version": "0.58.0",
+  "version": "0.59.0",
   "description": "Axstack installer and setup CLI: installs owned chat skills and role data, configures supported harness settings, and checks T3 Code capabilities.",
   "keywords": [
     "claude-code",

package/skills/axstack/references/independent-delivery.md

@@ -0,0 +1,68 @@
+# Independent delivery
+
+Apply this contract during Spec, Tickets and Implement within the accepted
+scope identity. Keep the existing spec, ticket map or small-change intent as
+the record; this adds neither a planning artifact nor execution authority.
+
+## Plan outcomes and boundaries
+
+Spec must name independently deliverable outcomes, their acceptance checks,
+and produced and consumed interfaces. An outcome is independently deliverable
+when its accepted result can be verified and delivered without waiting for an
+unrelated outcome. Shared files, interfaces, release targets and other scarce
+resources can still constrain execution.
+
+Tickets must map each outcome to an accountable scope driver marked accepted
+or proposed, write and resource boundaries, dependency milestones, and evidence
+with invalidation conditions. Record what a consumer actually needs: for
+example an accepted immutable interface, a versioned artifact, an exact
+reviewed code revision, or a merged change. Choose the sufficient milestone
+from acceptance and integration needs rather than requiring every producer to
+be reviewed or merged. Mapping can leave actual SHAs unresolved until execution.
+
+Default to separate accountable scope drivers for independent outcomes when
+explicitly authorized and supported by the runtime. Tasks within an accepted
+scope remain native delegates of its accountable driver. Reuse accepted owners
+and current attempts before proposing new drivers. Follow
+[Coordinating multiple drivers](t3-runtime.md#coordinating-multiple-drivers)
+for project binding, acceptance handbacks, record ownership and launch rules.
+
+Planning never grants launch permission or execution authority. Missing
+new-driver launch permission holds only that launch, subject to dependency and
+scoped-hold rules. The existing driver can progress only work already inside
+its accepted authority. A proposed scope driver is a plan entry, not an
+accepted owner. Preserve existing owners until an explicit accepted transfer
+under [Lifecycle](lifecycle.md#native-handoff-and-resume).
+
+## Admit and reconcile during execution
+
+During Implement, admit newly discovered independent outcomes through the same
+scope, interface and dependency map. Reuse the accepted scope where it covers
+the work; materially changed scope follows the existing approval boundary.
+Before dispatch, reconcile semantic and write conflicts, milestone and
+revision evidence, ownership and current attempts, writer exclusivity and
+capacity with native and forge state. Separate worktrees never prove semantic
+independence. Queue conflicting work or resolve its boundaries before dispatch;
+keep one writer per candidate and record. Driver separation alone grants no
+additional capacity or routing authority.
+
+Use main or the recorded integration target as the branch base unless a genuine
+unfinished code predecessor requires its exact reviewed revision. An artifact-only
+dependency can be satisfied by an accepted immutable interface or artifact
+milestone without Git ancestry. Follow [PR chains](pr-chain.md) for actual code
+ancestry, reviewed-parent branching, child invalidation and base updates.
+
+Bind each consumed milestone to actual current evidence at execution, including
+the producer revision or immutable artifact identity, receipt and acceptance
+state. Unknown or stale dependency evidence holds affected consumers until
+reconciled. When a producer revision changes, invalidate affected consumer
+evidence and revalidate those consumers while unrelated scopes progress.
+Keep artifact identities and code revisions distinct when determining which
+consumers are affected. A planned dependency or completion message alone is
+insufficient execution evidence.
+
+Follow [Lifecycle receipts](lifecycle.md#receipts-bind-each-decision-to-evidence)
+for current-attempt completion and advancement, [Autopilot](autopilot.md#advance-and-hold)
+for scoped and run-wide holds, and [Implement](../../axstack-implement/SKILL.md)
+for dispatch, review and delivery gates. This contract changes none of their
+ownership, serial preflight, capacity, hold, merge or completion requirements.

package/skills/axstack-implement/SKILL.md

@@ -19,6 +19,8 @@ run later reconciles merges and closes out.
 
 ## 1. Admit the work
 
+At admission and before dispatch, load and follow [Independent delivery](../axstack/references/independent-delivery.md).
+
 Before consequential work, load the standing contracts, follow their required
 edge into the lifecycle (including its audit hook), then apply shared routing:
 
@@ -205,6 +207,7 @@ Record: <progress.md path or tiny-task brief>
 Candidate: <PR or branch> base <sha> revision <sha>
 Owner: <profile + session ID + worktree>
 Scope: <approved spec + capability | small-change intent | maintenance snapshot>
+Delivery map: <record pointer; outcomes/accepted scope drivers; current milestone evidence; held launches>
 Shape: <total> lines vs base <sha>; bulk: <buckets>; theme: <one line>
 TDD: <normal red/green | structure-preserving old-green/same-check-new-green evidence | F-repair base-green/removal-inversion-red/rewording-green evidence>
 Token limit: <staged-file size check command + observed advisories/errors before each commit>

package/skills/axstack-spec/SKILL.md

@@ -25,6 +25,8 @@ and the lifecycle's [audit skill](../axstack-audit/SKILL.md) hook.
 
 ## Procedure
 
+Before drafting, load and follow [Independent delivery](../axstack/references/independent-delivery.md).
+
 1. **Select the authoritative store.** Use Linear through the executor MCP only
    for repositories in `defi-com`. Keep specs for other repositories on GitHub;
    if the issue, PR or repository-file location is unclear, ask before creating

package/skills/axstack-spec/references/format.md

@@ -22,6 +22,11 @@ or risk only in supporting detail.
 
 ## Execution requirements
 
+Follow [Independent delivery](../../axstack/references/independent-delivery.md)
+when planning outcomes. In execution requirements, describe each outcome with
+acceptance and produced and consumed interfaces. Keep these in the existing
+specification rather than a separate delivery artifact.
+
 Group precise requirements and observable acceptance by capability, using stable
 IDs where useful. Include behavior, interfaces, data, invariants, failure cases
 and validation that determine success. Put routine file-by-file task and PR
@@ -74,6 +79,9 @@ whole-dataset export and its cleanup cost. Proposed choice: filtered export.
 
 ## Execution requirements
 ### Filtered export
+Outcome: independently deliverable filtered CSV export.
+Produces: CSV rows in visible column order. Consumes: the existing table filter
+and column-order interfaces; no unfinished code predecessor is required.
 EXP-1: On click, capture the active filter and visible column order, label the
 action “Export filtered rows”, and export only matching rows in those columns.
 Acceptance for EXP-1: with a two-row dataset and a filter matching one row,

package/skills/axstack-tickets/SKILL.md

@@ -25,6 +25,8 @@ no dispatch preflight.
 
 ## Procedure
 
+Before mapping, load and follow [Independent delivery](../axstack/references/independent-delivery.md).
+
 1. **Pin scope and storage.** Confirm the approved spec identity before mapping.
    Hold on unapproved or materially changed scope; a still-valid approval is
    never repeated. Use the explicitly selected Markdown, GitHub Issues, or
@@ -71,11 +73,19 @@ no dispatch preflight.
 ```text
 Spec: <approved revision>
 Capability: <Markdown ref, GitHub issue URL, or Linear issue URL> <title>
+Outcome: <independently deliverable result>
+Scope: <accepted boundary>
+Driver: <accepted or proposed accountable scope driver + record/link>
 Internal task: <task> -> <PR owner> -> <worktree>
+Writes/resources: <write, semantic-interface and shared-resource boundaries>
+Produces/consumes: <interfaces or artifacts>
 Theme: <one behavior or component>
 Size est: <coarse size estimate>
 Acceptance: <checks from approved spec rev>
 Depends: <task IDs or none>
+Milestones: <per dependency: required acceptance state + producer/artifact identity; planned revisions allowed>
+Evidence/invalidation: <required receipt/check + producer changes that invalidate affected consumers>
+Branch: <main/integration target | exact reviewed unfinished code predecessor + reason>
 ```
 
 4. **Reconcile lifecycle state.** Compare each run capability with its required