axstack 0.18.0 → 0.19.0

package/README.md

@@ -24,6 +24,8 @@ without changing authority.
    reason. Small, bounded one-PR work uses the current request or selected issue
    as a snapshotted small-change intent;
    substantial or stacked work needs an approved spec and matching ticket map.
+   Substantial work uses Linear by default, or explicitly selected GitHub Issues
+   or repository Markdown, as its authoritative spec and capability tracker.
 2. The current chat drives on whatever model runs it; there is no driver
    profile. Bind each ready task to the selected role snapshot and an authoritative Orca
    Run, Task, and Dispatch. Exactly one writer owns a candidate at a time. All

package/docs/workflows.md

@@ -118,10 +118,13 @@ session and evidence remain valid.
   synthesis as the recommendation; the note lands as `Decisions` rows in the
   run record.
 - `axstack-spec` writes observable acceptance, exclusions, decisions, and one
-  user-approved revision baseline.
+  user-approved revision baseline. Linear is the default authoritative store;
+  GitHub Issues and repository Markdown are explicit alternatives. A GitHub
+  baseline pins the issue URL and approved body digest.
 - `axstack-tickets` maps user-visible capabilities to dependency-aware internal
-  tasks. Linear is the default selected store with access preflight; repository
-  Markdown is explicit fallback. Only the driver mutates lifecycle state.
+  tasks. Linear is the default selected store with access preflight; GitHub
+  Issues is an explicit external-tracker alternative and repository Markdown
+  is an explicit local alternative. Only the driver mutates lifecycle state.
 - `axstack-implement` uses strict behavioral RED, GREEN, then refactor. The
   narrow accepted structure-preserving route uses old-green and the same check
   new-green. One author writes and returns a local receipt without pushing. The

package/package.json

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

package/profiles/presets/claude-only.json

@@ -57,12 +57,12 @@
     },
     {
       "id": "axstack-checker",
-      "name": "Axstack Linear checker",
+      "name": "Axstack tracker checker",
       "provider": "claude",
       "model": "claude-sonnet-5",
       "modeId": "bypassPermissions",
       "thinkingOptionId": "low",
-      "notes": "Report-only Linear discrepancy checker. Never mutates Linear; the driver independently verifies evidence before applying updates. A null model means explicit user selection is required before dispatch and must never launch a provider default."
+      "notes": "Report-only discrepancy checker for the selected external tracker (Linear or GitHub Issues). Never mutates the tracker; the driver independently verifies evidence before applying updates. A null model means explicit user selection is required before dispatch and must never launch a provider default."
     },
     {
       "id": "axstack-research-requirements",

package/profiles/presets/codex-only.json

@@ -57,12 +57,12 @@
     },
     {
       "id": "axstack-checker",
-      "name": "Axstack Linear checker",
+      "name": "Axstack tracker checker",
       "provider": "codex",
       "model": "gpt-5.6-luna",
       "modeId": "full-access",
       "thinkingOptionId": "low",
-      "notes": "Report-only Linear discrepancy checker. Never mutates Linear; the driver independently verifies evidence before applying updates. A null model means explicit user selection is required before dispatch and must never launch a provider default."
+      "notes": "Report-only discrepancy checker for the selected external tracker (Linear or GitHub Issues). Never mutates the tracker; the driver independently verifies evidence before applying updates. A null model means explicit user selection is required before dispatch and must never launch a provider default."
     },
     {
       "id": "axstack-research-requirements",

package/profiles/presets/mixed.json

@@ -57,12 +57,12 @@
     },
     {
       "id": "axstack-checker",
-      "name": "Axstack Linear checker",
+      "name": "Axstack tracker checker",
       "provider": "antigravity",
       "model": null,
       "modeId": "full-access",
       "thinkingOptionId": "low",
-      "notes": "Report-only Linear discrepancy checker. Never mutates Linear; the driver independently verifies evidence before applying updates. Cheap report-only seat on Gemini Flash; launch by agent id antigravity."
+      "notes": "Report-only discrepancy checker for the selected external tracker (Linear or GitHub Issues). Never mutates the tracker; the driver independently verifies evidence before applying updates. Cheap report-only seat on Gemini Flash; launch by agent id antigravity."
     },
     {
       "id": "axstack-research-requirements",

package/skills/axstack/references/contracts.md

@@ -88,7 +88,7 @@ gate.
 ## Authority
 
 - The driver owns run scope, cross-PR coordination, integration, and every
-  Linear mutation. The checker reports discrepancies only.
+  selected external-tracker mutation. The checker reports discrepancies only.
 - One Orca execution host owns a run. There is no fixed active-PR count;
   fanout is dependency- and capacity-driven within configured host resource and
   spending limits. The driver reduces fanout when the run record shows rework,

package/skills/axstack/references/lifecycle.md

@@ -6,8 +6,8 @@ binding state and receipts to exact revisions.
 
 ## Roster (compact)
 
-- Driver: current chat; owns scope, decisions, cross-PR dependencies, Linear
-  mutations, and integration.
+- Driver: current chat; owns scope, decisions, cross-PR dependencies,
+  external-tracker mutations, integration.
 - Owner: driver owns loop PRs; `axstack-owner` only for standalone watch/review
   without live driver. It may perform PR-scoped publication within user authority. Human
   merge is default.
@@ -23,19 +23,19 @@ binding state and receipts to exact revisions.
 
 Prefer parallel independent bounded work; no redundant workers.
 Per [standing contracts](contracts.md), fanout is dependency/capacity-driven
-with no fixed count, within host and spending limits. [PR shape](pr-shape.md)
+with no fixed count within host/spending limits. [PR shape](pr-shape.md)
 covers theme/size; queue via `gh stack`.
 
 ## Ownership
 
-The PR owner remains accountable for candidate, fixes, evidence, and monitoring;
+The PR owner remains accountable for candidate, fixes, evidence, monitoring;
 peer code stays read-only. Missing or idle sessions never transfer ownership.
 Owned implementation enters review through the revision-bound
 [candidate-publication boundary](candidate-publication.md).
 
 ## Native handoff and resume
 
-Preparation completion/watch expiry writes a resumable record. Ordinary resume
+Preparation completion/watch expiry writes a record. Ordinary resume
 reconciles it, keeps the current owner, and launches no native handoff.
 Only an explicit user request to transfer ownership enters this branch.
 
@@ -45,7 +45,7 @@ Only an explicit user request to transfer ownership enters this branch.
 2. Load the [Orca runtime boundary](orca-runtime.md), then follow its
    version-matched runtime-owned handoff guidance. Never guess calls, paths,
    roles, or fallback models. Guide discovery does not prove capability.
-3. If the required native capability is missing, report the exact setup gap and
+3. If the native capability is missing, report the exact setup gap and
    keep the current owner; no replacement or ownership transfer launches.
    Read-only reconciliation may continue.
 4. Record recipient/pending receipt before launch. If uncertain, reconcile the
@@ -59,7 +59,7 @@ receipts/timers, unresolved decisions, next action, and transfer ownership/gap.
 
 ## Receipts (bind each decision to evidence)
 
-Store concise receipt references, not raw worker output, in the [Run record](run-record.md).
+Store receipt references, not raw output, in the [Run record](run-record.md).
 
 - Session receipt: actual agent/workspace IDs, requested provider/model and
   role; reuse on resume rather than spawn a replacement.
@@ -133,8 +133,8 @@ terminal; (2) compact record with counts and denominators—user
 interventions/deviations from plan/repairs; (3) `axstack-auditor`: settle
 non-zero/requested, else `counts zero`; an unavailable auditor leaves close-out
 pending, never skipped silently; (4) release merged run worktrees and branches;
-close Linear tickets; (5) mark the [Run record](run-record.md) `Archived`.
-`Archived`—one each:
+close selected external-tracker tickets when applicable; (5) mark the
+[Run record](run-record.md) `Archived`. `Archived`—one each:
 settlement receipt; compact record path; auditor decision plus settlement
 receipt or `counts zero`; release and ticket receipts; archive timestamp.
 `active`/receipt-incomplete record: close-out pending, never done. One-step

package/skills/axstack/references/routing.md

@@ -1,6 +1,6 @@
 # Shared routing (every owned phase loads this)
 
-Choose one route; load only the phase and references needed next.
+Choose a route; load only the phase and references needed next.
 
 ## Role routing
 
@@ -92,7 +92,7 @@ reason in the run record, or in the brief for tiny direct work.
   bounded small feature is not substantial because it is labelled one.
   Require an approved spec plus a ticket map tied to that exact spec
   revision, with acceptance checks and dependencies in the explicitly selected
-  Markdown or Linear store. Prepare via `axstack-align` -> `axstack-spec`
+  Markdown, GitHub Issues, or Linear store. Prepare via `axstack-align` -> `axstack-spec`
   (one approval) -> `axstack-tickets` -> handoff, then stop.
 - **Small:** clear, bounded one-PR work. The driver captures the named
   **small-change intent** from the current request or user-chosen existing

package/skills/axstack-spec/SKILL.md

@@ -15,15 +15,19 @@ and the lifecycle's [audit skill](../axstack-audit/SKILL.md) hook.
 ## Procedure
 
 1. **Select the authoritative store.** Use a native Linear document by
-   default, or repository Markdown when the user explicitly selects it.
-   Name the store before writing; one recorded choice leaves no implicit
-   fallback.
-2. **Preflight Linear access.** In Linear mode, verify that the current
+   default, or GitHub Issues or repository Markdown when the user explicitly
+   selects either alternative. Name the store before writing; one recorded
+   choice leaves no implicit fallback.
+2. **Preflight external-tracker access.** In Linear mode, verify that the current
    session can read, create, and update documents before any document write.
    Missing access is an actionable setup gap: report it and stop this phase
    without writing or changing stores. Linear drafting starts only when all
    three operations are available; a later tickets-phase check cannot replace
-   this one. Markdown mode skips this preflight.
+   this one. In GitHub mode, use authenticated `gh` to verify the target
+   repository, issues enabled, and the current identity's issue read and write
+   access before any issue write. Record the repository and identity checked.
+   Missing access preserves the GitHub selection and stops the phase without
+   mutation or fallback. Markdown mode skips external access preflight.
 3. **Draft with decision evidence.** Write observable acceptance criteria
    and explicit exclusions in the selected store. First record the driver's
    independent assessment, then load
@@ -42,12 +46,14 @@ and the lifecycle's [audit skill](../axstack-audit/SKILL.md) hook.
    creates the execution baseline.
 5. **Snapshot the baseline.** Record the approved revision identity and a
    concise repository Markdown counterpart. In Linear mode, the native
-   document remains authoritative; in Markdown mode, the agreed repository
-   path does. Use this shape:
+   document remains authoritative. In GitHub mode, the approved issue body is
+   authoritative and its GitHub issue URL plus SHA-256 body digest identifies
+   the exact approved revision. In Markdown mode, the agreed repository path does.
+   Use this shape:
 
 ```text
 Approved spec: <title> rev <id> (<date>)
-Authoritative store: <Linear document URL | repo Markdown path>
+Authoritative store: <Linear document URL + revision | GitHub issue URL + SHA-256 body digest | repo Markdown path + ref>
 Markdown counterpart: <repo path + ref>
 Baseline preserved at: <ref>
 Material change: <none | description + affected PRs/tasks + hold state>

package/skills/axstack-tickets/SKILL.md

@@ -20,20 +20,24 @@ an actual checker dispatch, not for ordinary mapping or state reconciliation.
 
 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 or Linear store. Record
-   the exact approved spec revision and selected store.
+   never repeated. Use the explicitly selected Markdown, GitHub Issues, or
+   Linear store. Record the exact approved spec revision and selected store.
 
 2. **Preflight the selected store.** Markdown mode works independently. In
    Linear mode, check the actual session's required MCP tools and document
    access. Missing access is an actionable setup gap: preserve the selected
    store, record the gap, and stop affected work. Proceed only with verified
-   access; a recorded gap never switches stores.
+   access; a recorded gap never switches stores. In GitHub mode, use
+   authenticated `gh` to verify the target repository and issue access for the
+   current identity before reading or writing the capability map. Preserve the
+   selected store and stop affected work on an access gap.
 
-3. **Map capabilities to execution.** In Linear, issues represent user-visible
-   capabilities; one capability may span several tasks and PRs. Keep detailed
-   execution breakdowns in the repository. For every capability, derive
-   acceptance checks from the pinned spec and identify internal tasks,
-   dependencies, PR ownership, and worktrees. For each task the driver records
+3. **Map capabilities to execution.** In Linear and GitHub Issues,
+   issues represent user-visible capabilities; one capability may span several
+   tasks and PRs. GitHub capability issues link the approved spec issue and its
+   SHA-256 body digest. Keep detailed execution breakdowns in the repository.
+   For every capability, derive acceptance checks from the pinned spec and
+   identify internal tasks, dependencies, PR ownership, and worktrees. For each task the driver records
    one theme and a coarse size estimate from the ownership, interface, and
    dependency map. A task estimated in the exception band is assessed for a
    split at mapping time and split where a green, atomic, reviewable split
@@ -44,14 +48,14 @@ an actual checker dispatch, not for ordinary mapping or state reconciliation.
    These routine mapping and split choices are autonomous driver decisions
    within the approved spec; size alone never requires user approval.
 
-   The driver performs every Linear mutation. Other roles return proposed
-   changes and evidence to the driver.
+   The driver performs every mutation in the selected external tracker. Other
+   roles return proposed changes and evidence to the driver.
 
 ## Template: capability to task map
 
 ```text
 Spec: <approved revision>
-Capability: <Markdown ref or Linear issue URL> <title>
+Capability: <Markdown ref, GitHub issue URL, or Linear issue URL> <title>
 Internal task: <task> -> <PR owner> -> <worktree>
 Theme: <one behavior or component>
 Size est: <coarse band estimate>
@@ -60,24 +64,26 @@ Depends: <task IDs or none>
 ```
 
 4. **Reconcile lifecycle state.** Compare each run capability with its required
-   PR merge evidence and acceptance outputs. A reviewed but unmerged capability
-   stays **In Review**; mark Done only after all required PRs merge and the
-   capability's acceptance checks pass. Resolve each observed mismatch with
-   either a verified driver-owned update or a drift report.
+   PR merge evidence and acceptance outputs. In Linear or Markdown, a reviewed
+   but unmerged capability stays **In Review**; mark Done only after all required
+   PRs merge and its acceptance checks pass. A GitHub capability issue remains
+   open through review; close it only after all required PRs merge and its
+   acceptance checks pass. Resolve each observed mismatch with either a verified
+   driver-owned update or a drift report.
 
    The checker reports run-scoped discrepancies with evidence and never mutates
-   Linear. The driver independently verifies that evidence before applying an
-   update. Spec or acceptance changes and conflicting state are decisions, not
-   routine sync repairs. With no configured `axstack-checker` profile, hold
-   checker dispatch; the driver checks directly or records the gap. Never launch
-   a provider default.
+   the selected external tracker. The driver independently verifies that
+   evidence before applying an update. Spec or acceptance changes and
+   conflicting state are decisions, not routine sync repairs. With no
+   configured `axstack-checker` profile, hold checker dispatch; the driver
+   checks directly or records the gap. Never launch a provider default.
 
 ### Template: drift report
 
 ```text
 Capability: <issue>
-Observed: <Linear state> vs <PR merge SHAs/URLs + acceptance outputs>
-Recommendation: <move to In Review | other> (driver verifies first)
+Observed: <selected tracker state> vs <PR merge SHAs/URLs + acceptance outputs>
+Recommendation: <move to In Review | keep open | close | other> (driver verifies first)
 ```
 
 5. **Return the mapping.** Report the pinned spec revision, selected store, map