taskledger 0.4.2__tar.gz → 0.5.0__tar.gz

taskledger-0.5.0/.archledger/archive/records/building_blocks/al_block_0083.md

@@ -0,0 +1,41 @@
+---
+schema_version: 2
+id: al_block_0083
+type: black_box
+title: Human Presentation Layer
+status: archived
+section: building_block_view
+level: 1
+parent: al_block_0029
+order: 60
+date: "2026-06-07"
+interfaces:
+  - Service read models -> terminal TUI
+  - Dashboard/report payloads -> HTML or Markdown
+location:
+  - taskledger/tui/
+  - taskledger/services/tui_read_model.py
+  - taskledger/services/dashboard.py
+  - taskledger/services/task_reports.py
+fulfilled_requirements: []
+risks: []
+tags: []
+body_format: markdown
+created_at: "2026-06-07T11:49:59Z"
+updated_at: "2026-06-11T20:53:29Z"
+source_refs:
+  - path: taskledger/tui/
+    role: implements
+  - path: taskledger/services/tui_read_model.py
+    role: implements
+test_refs:
+  - tests/test_tui_cli.py
+  - tests/test_tui_read_model.py
+archived_at: "2026-06-11T20:53:29Z"
+archived_reason: TUI and HTML dashboard removed from taskledger; task-0126 ledger-isolation
+archived_from: records/building_blocks/al_block_0083.md
+---
+
+Optional human-facing views over the same durable task records used by CLI and API operations. The Textual TUI presents task lists, plan review, todos, implementation, code reviews, validation, files, events, and raw reports. HTML dashboard and Markdown report services provide related inspection and sharing views.
+
+This layer is read-only with respect to lifecycle state. Users invoke explicit CLI commands for mutations, preserving approval, lock, todo, and validation gates.

taskledger-0.5.0/.archledger/archive/records/concepts/al_concept_0081.md

@@ -0,0 +1,32 @@
+---
+schema_version: 2
+id: al_concept_0081
+type: concept
+title: BDD traceability and report evidence
+status: archived
+section: cross_cutting_concepts
+order: 70
+date: "2026-06-07"
+applies_to: []
+body_format: markdown
+created_at: "2026-06-07T11:49:58Z"
+updated_at: "2026-06-11T20:53:29Z"
+source_refs:
+  - path: taskledger/domain/bdd.py
+    role: implements
+  - path: taskledger/services/bdd_gherkin.py
+    role: implements
+  - path: taskledger/services/bdd_reports.py
+    role: implements
+test_refs:
+  - tests/test_bdd_gherkin.py
+  - tests/test_bdd_report_import.py
+  - tests/test_bdd_validation_integration.py
+archived_at: "2026-06-11T20:53:29Z"
+archived_reason: BDD traceability removed from taskledger; task-0126 ledger-isolation
+archived_from: records/concepts/al_concept_0081.md
+---
+
+BDD is an optional traceability overlay on a managed task. Features contain rules and Given/When/Then examples. Examples can reference canonical acceptance-criterion IDs and Archledger record IDs.
+
+Gherkin export is an exchange artifact, not canonical state. Stable tags preserve task, example, criterion, and architecture identities. Imported Cucumber JSON or JUnit XML is matched back to examples and persisted as report evidence that can contribute validation checks. Normal lifecycle and validation gates remain authoritative.

{taskledger-0.4.2/.archledger → taskledger-0.5.0/.archledger/archive}/records/runtime/al_runtime_0076.md

@@ -2,17 +2,20 @@
 schema_version: 2
 id: al_runtime_0076
 type: runtime_scenario
-title: "HTML report and serve dashboard"
-status: accepted
+title: HTML report and serve dashboard
+status: archived
 section: runtime_view
 order: 70
 date: "2026-05-23"
 participants: []
-trigger: "Developer runs taskledger report html or taskledger serve"
+trigger: Developer runs taskledger report html or taskledger serve
 result: ""
 body_format: markdown
 created_at: "2026-05-23T19:30:00Z"
-updated_at: "2026-05-23T19:30:00Z"
+updated_at: "2026-06-11T20:54:44Z"
+archived_at: "2026-06-11T20:54:44Z"
+archived_reason: HTML report and serve dashboard removed; task-0126 ledger-isolation
+archived_from: records/runtime/al_runtime_0076.md
 ---
 
 **Trigger**: Developer runs `taskledger report html` or `taskledger serve`.

taskledger-0.5.0/.archledger/archive/records/runtime/al_runtime_0084.md

@@ -0,0 +1,42 @@
+---
+schema_version: 2
+id: al_runtime_0084
+type: runtime_scenario
+title: BDD example to validation evidence
+status: archived
+section: runtime_view
+order: 100
+date: "2026-06-07"
+participants:
+  - coding agent
+  - taskledger CLI
+  - BDD services
+  - task storage
+trigger: An actor wants executable examples linked to task acceptance criteria.
+result: External automation results are persisted as traceable validation evidence.
+body_format: markdown
+created_at: "2026-06-07T11:50:18Z"
+updated_at: "2026-06-11T20:53:29Z"
+source_refs:
+  - path: taskledger/cli_bdd.py
+    role: implements
+  - path: taskledger/services/bdd_gherkin.py
+    role: implements
+  - path: taskledger/services/bdd_reports.py
+    role: implements
+test_refs:
+  - tests/test_bdd_cli.py
+  - tests/test_bdd_validation_integration.py
+archived_at: "2026-06-11T20:53:29Z"
+archived_reason: BDD example scenario removed from taskledger; task-0126 ledger-isolation
+archived_from: records/runtime/al_runtime_0084.md
+---
+
+1. An actor initializes task-local BDD/example records for a managed task.
+2. Each example links to acceptance-criterion IDs and may link to Archledger records.
+3. Canonical behavior specs live outside Taskledger under `specs/behavior/features/<area>/<feature>.feature`, owned by SpecWeave.
+4. Plain pytest files under `tests/test_<area>_<feature>.py` enforce the behavior and may emit JUnit XML under `reports/behavior/`.
+5. `bdd example link-automation` records metadata that links a task-local example to the external feature file, scenario tag/title, and pytest node id.
+6. `validate import-bdd-report` imports JUnit XML or Cucumber-compatible JSON evidence and matches it back to task-local examples.
+7. Matched results become validation evidence through normal validation checks; normal latest-check-wins and mandatory-criterion gates still decide completion.
+8. `bdd gherkin-export` remains a derived exchange/export command. It must not be presented as the canonical source of executable behavior.

{taskledger-0.4.2/.archledger → taskledger-0.5.0/.archledger/profiles/arc42}/sections/al_content_0002.md

@@ -14,7 +14,7 @@ updated_at: "2026-05-23T12:24:46Z"
 
 taskledger operates under several fixed constraints that shape its architecture:
 
-- **Python 3.10+ with minimal dependencies**: The runtime depends only on `typer`, `PyYAML`, `Jinja2`, `markdown-it-py`, and `tomli` (for Python <3.11). No database, no network server, no external service is required.
+- **Python 3.10+ with minimal dependencies**: The runtime depends only on `typer`, `PyYAML`, and `tomli` (for Python <3.11). No database, no network server, no external service is required.
 - **File-system canonical storage**: All durable state lives in the project's `.taskledger/` directory as Markdown files with YAML front matter. This makes state inspectable, diffable, and version-controllable alongside source code.
 - **CLI-first with machine-readable JSON output**: The primary interface is the `taskledger` CLI command. Every command supports `--json` for structured output. The JSON envelope shape and exit codes are part of the public contract.
 - **Skills outside the package**: Agent skill files (e.g., `skills/taskledger/SKILL.md`) live outside the Python package and are never packaged as Python package data. The package provides the CLI/library; skill distribution is separate.

{taskledger-0.4.2/.archledger → taskledger-0.5.0/.archledger/profiles/arc42}/sections/al_content_0004.md

@@ -26,6 +26,7 @@ Key architectural choices:
 - **JSON indexes as derived caches** — Index files under `.taskledger/indexes/` are rebuilt from canonical records by `taskledger reindex`. They are never the source of truth.
 - **Policy-based gate decisions** — All lifecycle transitions go through functions in `taskledger/domain/policies.py` that return `Decision` objects with `allowed`, `code`, `message`, and `exit_code`. This keeps gate logic testable and separate from I/O.
 - **Atomic file writes** — All writes use `atomic_write_text` (write to temp, `os.replace`) to prevent partial writes on crash.
+- **Evidence as sidecars** — Code-review records extend traceability without introducing new lifecycle stages or weakening validation gates.
 
 ## Maintenance
 

{taskledger-0.4.2/.archledger → taskledger-0.5.0/.archledger/profiles/arc42}/sections/al_content_0005.md

@@ -22,4 +22,4 @@ The top-level building block is the **taskledger system**, decomposed into five
 
 Data flows strictly downward: CLI → Services → Domain + Storage. The API layer calls Services directly. The Domain layer has no dependencies on Storage or Services.
 
-Each task is stored as a **task bundle directory** under `.taskledger/ledgers/<ledger_ref>/` containing the task record (Markdown) and sidecar collections for plans, runs, locks, todos, questions, changes, checks, handoffs, and links. When `[event_logging] enabled = true` in `taskledger.toml`, mutations append immutable `TaskEvent` records to the ledger-level `events/` directory. Event logging is disabled by default.
+Each task is stored as a **task bundle directory** under `.taskledger/ledgers/<ledger_ref>/` containing the task record (Markdown) and sidecar collections for plans, runs, locks, todos, questions, changes, checks, handoffs, and links. Mutations append immutable `TaskEvent` records to the ledger-level `events/` directory. Action/event logging is enabled by default; set `[event_logging] enabled = false` in `taskledger.toml` to disable new event records. Existing records remain readable regardless.

{taskledger-0.4.2/.archledger → taskledger-0.5.0/.archledger/profiles/arc42}/sections/al_content_0006.md

@@ -18,3 +18,5 @@ The runtime view traces the main operational scenarios through the system:
 2. **Lock lifecycle** — Starting a stage (planning/implementation/validation) acquires a lock and creates a run. Locks have lease timers and heartbeats. Stale locks require explicit break flow with audit trail.
 3. **Handoff flow** — A worker creates a handoff with generated context (task state, plan, todos, questions, lock info). Another worker claims it, optionally transferring the lock. The handoff is closed when the receiving worker completes.
 4. **Doctor checks** — Inspects lock/run consistency, front matter integrity, index staleness, and storage layout version. Reports diagnostics with severity, code, and repair hints.
+5. **Validation evidence flow** — Acceptance criteria from the accepted plan are checked during the validation stage. Evidence is recorded per criterion with pass/fail/warn status. Latest-check-wins semantics apply; mandatory criteria gate completion.
+6. **Code-review evidence** — A reviewer records append-only review evidence against an implementation run, handoff, worker step, working tree, or commit. This is evidence attached to the task, not a new lifecycle stage.

{taskledger-0.4.2/.archledger → taskledger-0.5.0/.archledger/profiles/arc42}/sections/al_content_0007.md

@@ -16,6 +16,6 @@ taskledger is a single-node, file-system-based tool. Deployment consists of:
 
 - **Installation**: `pip install taskledger` (PyPI) or local `pip install -e .`
 - **Project initialization**: `taskledger init` creates `taskledger.toml` and `.taskledger/` in the project root
-- **Runtime**: The CLI runs as a Python process, reading and writing the project's `.taskledger/` directory. No daemon, no server (except optional `taskledger serve` for a local web dashboard).
+- **Runtime**: The CLI runs as a Python process, reading and writing the project's `.taskledger/` directory. No daemon, no server.
 - **CI integration**: taskledger commands can be run in CI pipelines for status checks and validation
 - **Agent integration**: Agent harnesses invoke taskledger CLI commands as subprocess calls

{taskledger-0.4.2/.archledger → taskledger-0.5.0/.archledger/profiles/arc42}/sections/al_content_0008.md

@@ -18,5 +18,7 @@ Cross-cutting concerns that span multiple layers:
 - **JSON output envelope**: All CLI commands emit a consistent JSON envelope with `ok`, `command`, `result_type`, `result`, `events`, and `warnings` fields when `--json` is passed.
 - **YAML front matter serialization**: All canonical records use YAML front matter (`---` delimited) for metadata and Markdown for body. Serialization/deserialization is in `taskledger/storage/frontmatter.py`.
 - **Atomic file writes**: All file writes go through `atomic_write_text` (temp file → `os.replace` → directory fsync) to prevent corruption.
-- **Opt-in event logging**: When `[event_logging] enabled = true`, mutations append immutable `TaskEvent` records to the ledger-level `events/` directory under `.taskledger/ledgers/<ledger_ref>/`. When disabled (default), no new event records are written; existing records remain readable. Events track who did what, when, and why. Source: `taskledger/storage/events.py`, `taskledger/services/task_events.py`.
+- **Action/event logging (default-on)**: Mutations append immutable `TaskEvent` records to the ledger-level `events/` directory under `.taskledger/ledgers/<ledger_ref>/`. Action/event logging is enabled by default; set `[event_logging] enabled = false` to disable new records. Existing records remain readable. Events track who did what, when, and why. Source: `taskledger/storage/events.py`, `taskledger/services/task_events.py`.
 - **Exit code taxonomy**: Errors map to stable exit codes (0=success, 1=generic, 2=bad input, 3=workflow rejection, 4=lock conflict, 5=missing, 6=storage, 7=validation failed).
+- **Opaque cross-ledger references**: Links and file references remain opaque strings. Taskledger does not interpret archledger IDs, SpecWeave feature paths, or other external system references.
+- **Read-model reuse**: `view` and `status` commands consume service-level read models. These presentations are read-only and do not bypass lifecycle services.

{taskledger-0.4.2/.archledger → taskledger-0.5.0/.archledger/profiles/arc42}/sections/al_content_0011.md

@@ -17,4 +17,4 @@ Known risks and areas of technical debt:
 - **Storage scaling with many tasks**: Each task is a directory with multiple sidecar files. Very large projects (hundreds of tasks) may see slowdowns in list/query operations since indexes are rebuilt from file scans.
 - **Migration surface between storage versions**: The storage layout has evolved (currently v3). Migration code in `taskledger/storage/migrations.py` adds complexity. Future format changes must maintain backward compatibility.
 - **Service boundary erosion**: Some service modules (notably `tasks.py`) have grown large. The service layer has no formal interface contracts — boundaries are enforced by convention and tests (`test_service_boundaries.py`).
-- **Growing dependency count**: Jinja2 is used only for HTML report templates. The dependency is justified by the `serve` and `task report` features but adds weight for users who only need the CLI.
+- **Growing dependency count**: The dependency set is small (typer, PyYAML, tomli) but new dependencies must be justified by core features, not optional presentations.

{taskledger-0.4.2 → taskledger-0.5.0}/.archledger/records/building_blocks/al_block_0029.md

@@ -14,12 +14,12 @@ quality_characteristics: []
 tags: []
 body_format: markdown
 created_at: "2026-05-23T12:30:16Z"
-updated_at: "2026-05-23T12:30:16Z"
+updated_at: "2026-06-11T21:00:00Z"
 ---
 
 ## Motivation
 
-taskledger decomposes into five layers with strict downward dependency flow. This decomposition isolates I/O (storage), business rules (domain), orchestration (services), and presentation (CLI/API).
+taskledger decomposes into core layers with downward dependency flow. This isolates persistence, business rules, orchestration, and public interfaces.
 
 ## Contained building blocks
 

taskledger-0.5.0/.archledger/records/building_blocks/al_block_0030.md

@@ -0,0 +1,24 @@
+---
+schema_version: 2
+id: al_block_0030
+type: black_box
+title: "CLI Layer"
+status: accepted
+section: building_block_view
+level: 1
+parent: al_block_0029
+order: 10
+date: "2026-05-23"
+interfaces: []
+location: []
+fulfilled_requirements: []
+risks: []
+tags: []
+body_format: markdown
+created_at: "2026-05-23T12:30:23Z"
+updated_at: "2026-06-11T21:00:00Z"
+---
+
+Handles command parsing via Typer, task reference resolution (`--task` option, active task default), and output rendering (human text or JSON envelope via `cli_common.py`). Command families include the canonical lifecycle plus `review`, `config`, task archive operations, transfer/sync, diagnostics, and the `monitor` observer.
+
+Source refs: `taskledger/cli.py`, `taskledger/cli_common.py`, `taskledger/command_inventory.py`, and the focused `taskledger/cli_*.py` registration modules.

taskledger-0.5.0/.archledger/records/building_blocks/al_block_0032.md

@@ -0,0 +1,22 @@
+---
+schema_version: 2
+id: al_block_0032
+type: black_box
+title: "Services Layer"
+status: proposed
+section: building_block_view
+level: 1
+parent: al_block_0029
+order: 30
+date: "2026-05-23"
+interfaces: []
+location: []
+fulfilled_requirements: []
+risks: []
+tags: []
+body_format: markdown
+created_at: "2026-05-23T12:30:29Z"
+updated_at: "2026-06-11T21:00:00Z"
+---
+
+Orchestrates lifecycle flows by coordinating Domain policies and records with Storage. Focused services own planning, implementation, validation, handoffs, doctor checks, navigation, worker pipelines, archival, code-review evidence, event logging, exports, dashboard assembly, and ready-work inspection. `tasks.py` remains the compatibility-oriented lifecycle facade while ownership is progressively extracted into focused modules.

taskledger-0.5.0/.archledger/records/building_blocks/al_block_0033.md

@@ -0,0 +1,22 @@
+---
+schema_version: 2
+id: al_block_0033
+type: black_box
+title: "Domain Layer"
+status: proposed
+section: building_block_view
+level: 1
+parent: al_block_0029
+order: 40
+date: "2026-05-23"
+interfaces: []
+location: []
+fulfilled_requirements: []
+risks: []
+tags: []
+body_format: markdown
+created_at: "2026-05-23T12:30:29Z"
+updated_at: "2026-06-11T21:00:00Z"
+---
+
+Data models, state enums, normalization, and policy decisions without storage I/O. Besides lifecycle and sidecar records, the domain defines append-only code-review records. State transitions remain in `states.py`; policy decisions in `policies.py` return structured `Decision` objects.

taskledger-0.5.0/.archledger/records/building_blocks/al_block_0034.md

@@ -0,0 +1,22 @@
+---
+schema_version: 2
+id: al_block_0034
+type: black_box
+title: "Storage Layer"
+status: proposed
+section: building_block_view
+level: 1
+parent: al_block_0029
+order: 50
+date: "2026-05-23"
+interfaces: []
+location: []
+fulfilled_requirements: []
+risks: []
+tags: []
+body_format: markdown
+created_at: "2026-05-23T12:30:29Z"
+updated_at: "2026-06-11T21:00:00Z"
+---
+
+File system persistence for canonical records. Storage layout keeps each task in `.taskledger/ledgers/<ledger_ref>/tasks/<task-id>/`, with independently addressable sidecars including plans, runs, locks, todos, questions, changes, checks, handoffs, links, and code reviews. Ledger-level collections hold events, introductions, releases, and rebuildable indexes. Action/event logging is enabled by default and can be disabled in project config. Project config edits use structured TOML handling rather than ad hoc text replacement.

taskledger-0.5.0/.archledger/records/concepts/al_concept_0044.md

@@ -0,0 +1,16 @@
+---
+schema_version: 2
+id: al_concept_0044
+type: concept
+title: "Append-only event log"
+status: proposed
+section: cross_cutting_concepts
+order: 50
+date: "2026-05-23"
+applies_to: []
+body_format: markdown
+created_at: "2026-05-23T12:31:01Z"
+updated_at: "2026-05-23T12:31:01Z"
+---
+
+Mutations append an immutable `TaskEvent` record to the ledger-level `events/` directory under `.taskledger/ledgers/<ledger_ref>/`. Action/event logging is enabled by default; set `[event_logging] enabled = false` in `taskledger.toml` to disable new event records. Existing records remain readable regardless of the setting. Events are never modified or deleted. Each event has a deterministic ID, name (e.g., `task.created`, `plan.approved`, `lock.acquired`, `validation.check.logged`, `code_review.recorded`), timestamp, and actor metadata. Events support audit trails, monitor activity, handoff context, and `task transcript` output. Duplicate event detection prevents re-appending on retry. Source: `taskledger/storage/events.py`, `taskledger/services/task_events.py`, `taskledger/domain/event.py`.

taskledger-0.5.0/.archledger/records/concepts/al_concept_0082.md

@@ -0,0 +1,25 @@
+---
+schema_version: 2
+id: al_concept_0082
+type: concept
+title: "Durable code-review evidence"
+status: proposed
+section: cross_cutting_concepts
+order: 80
+date: "2026-06-07"
+applies_to: []
+body_format: markdown
+created_at: "2026-06-07T11:49:59Z"
+updated_at: "2026-06-07T11:49:59Z"
+source_refs:
+  - path: taskledger/domain/review.py
+    role: implements
+  - path: taskledger/services/code_review.py
+    role: implements
+test_refs:
+  - tests/test_code_reviews.py
+---
+
+Code review is durable evidence attached to a task. A record captures result, summary/body, reviewer and harness, implementation run, worker step, handoff, and optional Git working-tree or commit metadata.
+
+Review records are append-only and may be recorded after a task reaches `done`. They do not create a lifecycle stage, reopen completed work, replace acceptance criteria, or weaken validation completion rules.

taskledger-0.5.0/.archledger/records/constraints/al_constraint_0016.md

@@ -0,0 +1,17 @@
+---
+schema_version: 2
+id: al_constraint_0016
+type: constraint
+title: "Python 3.10+ with minimal dependencies"
+status: proposed
+section: architecture_constraints
+order: 10
+date: "2026-05-23"
+category: technical
+impact: "Limits runtime to Python 3.10+ with three dependencies; no database or native extensions."
+body_format: markdown
+created_at: "2026-05-23T12:29:53Z"
+updated_at: "2026-06-11T21:00:00Z"
+---
+
+Runtime dependencies are limited to `typer`, `PyYAML`, and `tomli` (Python <3.11 only). This constraint ensures easy installation in constrained environments (CI, containers, Termux) and avoids dependency conflicts with host projects. The trade-off is that features like full-text search use pure-Python implementations rather than native libraries.

{taskledger-0.4.2 → taskledger-0.5.0}/.archledger/records/decisions/al_adr_0046.md

@@ -2,18 +2,25 @@
 schema_version: 2
 id: al_adr_0046
 type: adr
-title: "Markdown/YAML front matter as canonical format"
+title: Markdown/YAML front matter as canonical format
 status: accepted
 section: architecture_decisions
 order: 10
 date: "2026-05-23"
-deciders: []
+deciders:
+  - taskledger maintainers
 supersedes: []
 related: []
 tags: []
 body_format: markdown
 created_at: "2026-05-23T12:31:02Z"
-updated_at: "2026-05-23T12:31:02Z"
+updated_at: "2026-06-07T11:50:15Z"
+source_refs:
+  - path: taskledger/storage/frontmatter.py
+    role: implements
+    reason: Canonical Markdown/YAML serialization
+test_refs:
+  - tests/test_storage_bundle_layout.py
 ---
 
 ## Context

{taskledger-0.4.2 → taskledger-0.5.0}/.archledger/records/decisions/al_adr_0047.md

@@ -2,18 +2,25 @@
 schema_version: 2
 id: al_adr_0047
 type: adr
-title: "JSON indexes as derived rebuildable caches"
+title: JSON indexes as derived rebuildable caches
 status: accepted
 section: architecture_decisions
 order: 20
 date: "2026-05-23"
-deciders: []
+deciders:
+  - taskledger maintainers
 supersedes: []
 related: []
 tags: []
 body_format: markdown
 created_at: "2026-05-23T12:31:02Z"
-updated_at: "2026-05-23T12:31:02Z"
+updated_at: "2026-06-07T11:50:16Z"
+source_refs:
+  - path: taskledger/storage/task_store.py
+    role: implements
+    reason: Derived index paths and rebuildable cache contract
+test_refs:
+  - tests/test_storage_sync.py
 ---
 
 ## Context

{taskledger-0.4.2 → taskledger-0.5.0}/.archledger/records/decisions/al_adr_0048.md

@@ -2,18 +2,25 @@
 schema_version: 2
 id: al_adr_0048
 type: adr
-title: "Explicit lifecycle gates with policy decisions"
+title: Explicit lifecycle gates with policy decisions
 status: accepted
 section: architecture_decisions
 order: 30
 date: "2026-05-23"
-deciders: []
+deciders:
+  - taskledger maintainers
 supersedes: []
 related: []
 tags: []
 body_format: markdown
 created_at: "2026-05-23T12:31:02Z"
-updated_at: "2026-05-23T12:31:02Z"
+updated_at: "2026-06-07T11:50:16Z"
+source_refs:
+  - path: taskledger/domain/policies.py
+    role: implements
+    reason: Lifecycle gate decisions
+test_refs:
+  - tests/test_domain_policies.py
 ---
 
 ## Context

{taskledger-0.4.2 → taskledger-0.5.0}/.archledger/records/decisions/al_adr_0049.md

@@ -2,18 +2,25 @@
 schema_version: 2
 id: al_adr_0049
 type: adr
-title: "Typer CLI framework"
+title: Typer CLI framework
 status: accepted
 section: architecture_decisions
 order: 40
 date: "2026-05-23"
-deciders: []
+deciders:
+  - taskledger maintainers
 supersedes: []
 related: []
 tags: []
 body_format: markdown
 created_at: "2026-05-23T12:31:03Z"
-updated_at: "2026-05-23T12:31:03Z"
+updated_at: "2026-06-07T11:50:17Z"
+source_refs:
+  - path: taskledger/cli.py
+    role: implements
+    reason: Root Typer application and command registration
+test_refs:
+  - tests/test_help_subprocess.py
 ---
 
 ## Context

{taskledger-0.4.2 → taskledger-0.5.0}/.archledger/records/decisions/al_adr_0050.md

@@ -2,27 +2,34 @@
 schema_version: 2
 id: al_adr_0050
 type: adr
-title: "Task bundle directory layout"
+title: Task bundle directory layout
 status: accepted
 section: architecture_decisions
 order: 50
 date: "2026-05-23"
-deciders: []
+deciders:
+  - taskledger maintainers
 supersedes: []
 related: []
 tags: []
 body_format: markdown
 created_at: "2026-05-23T12:31:03Z"
-updated_at: "2026-05-23T12:31:03Z"
+updated_at: "2026-06-07T11:50:17Z"
+source_refs:
+  - path: taskledger/storage/task_store.py
+    role: implements
+    reason: Task bundle layout v3
+test_refs:
+  - tests/test_storage_bundle_layout.py
 ---
 
 ## Context
 
-Need a storage layout that scales to many sidecar collections per task (plans, runs, locks, todos, questions, changes, checks, handoffs, links) while keeping each record individually addressable. Events are stored at ledger level, not per-task, and are opt-in.
+Need a storage layout that scales to many sidecar collections per task (plans, runs, locks, todos, questions, changes, checks, handoffs, links) while keeping each record individually addressable. Events are stored at ledger level, not per-task, and are enabled by default.
 
 ## Decision
 
-Use a directory-per-task layout (v2 bundle) under `.taskledger/ledgers/<ledger_ref>/`. Each task gets a directory containing the task record (Markdown) and subdirectories for sidecar collections. JSON indexes are derived caches at the ledger level. Event records are stored in the ledger-level `events/` directory (not per-task) and are only written when `[event_logging] enabled = true`.
+Use a directory-per-task layout (v2 bundle) under `.taskledger/ledgers/<ledger_ref>/`. Each task gets a directory containing the task record (Markdown) and subdirectories for sidecar collections. JSON indexes are derived caches at the ledger level. Event records are stored in the ledger-level `events/` directory (not per-task) and are written by default; set `[event_logging] enabled = false` to disable.
 
 ## Consequences
 

{taskledger-0.4.2 → taskledger-0.5.0}/.archledger/records/decisions/al_adr_0051.md

@@ -2,18 +2,25 @@
 schema_version: 2
 id: al_adr_0051
 type: adr
-title: "External skill packaging"
+title: External skill packaging
 status: accepted
 section: architecture_decisions
 order: 60
 date: "2026-05-23"
-deciders: []
+deciders:
+  - taskledger maintainers
 supersedes: []
 related: []
 tags: []
 body_format: markdown
 created_at: "2026-05-23T12:31:04Z"
-updated_at: "2026-05-23T12:31:04Z"
+updated_at: "2026-06-07T11:50:18Z"
+source_refs:
+  - path: pyproject.toml
+    role: implements
+    reason: Package-data boundary excludes skills
+test_refs:
+  - tests/test_docs_and_skill.py
 ---
 
 ## Context

{taskledger-0.4.2 → taskledger-0.5.0}/.archledger/records/deployment/al_deploy_0039.md

@@ -13,7 +13,7 @@ environment: "development"
 maps_building_blocks: []
 body_format: markdown
 created_at: "2026-05-23T12:30:52Z"
-updated_at: "2026-05-23T12:30:52Z"
+updated_at: "2026-06-11T21:00:00Z"
 ---
 
 **Node**: Developer workstation or CI runner
@@ -30,6 +30,6 @@ updated_at: "2026-05-23T12:30:52Z"
 - JSON index caches under `.taskledger/indexes/`
 - Project config at `taskledger.toml`
 
-**Network**: None required. Optional: `taskledger serve` starts a local HTTP dashboard.
+**Network**: None required.
 
 **Installation**: `pip install taskledger` or `pip install -e .` from source. Single entry point: `taskledger` CLI.

taskledger-0.5.0/.archledger/records/risks/al_risk_0060.md

@@ -0,0 +1,18 @@
+---
+schema_version: 2
+id: al_risk_0060
+type: risk
+title: "Growing dependency count"
+status: proposed
+section: risks_and_technical_debt
+order: 40
+date: "2026-05-23"
+severity: medium
+probability: medium
+mitigation: "Small dependency set (typer, PyYAML, tomli); each justified by a core feature."
+body_format: markdown
+created_at: "2026-05-23T12:31:20Z"
+updated_at: "2026-06-11T21:00:00Z"
+---
+
+The dependency set is small (typer, PyYAML, tomli) and each is justified by a core feature. Risk is low as long as new dependencies are not introduced without explicit justification.

{taskledger-0.4.2 → taskledger-0.5.0}/.archledger/records/stakeholders/al_content_0080.md

@@ -9,7 +9,7 @@ status: accepted
 date: "2026-05-25"
 body_format: markdown
 created_at: "2026-05-25T00:00:00Z"
-updated_at: "2026-05-25T00:00:00Z"
+updated_at: "2026-06-11T21:00:00Z"
 ---
 
-Human developers use taskledger through the CLI for task-first project management. They approve plans, waive acceptance criteria, create follow-up tasks, and inspect task state. They rely on concise human-readable output and the `serve` dashboard for project overview.
+Human developers use taskledger through the CLI for task-first project management. They approve plans, waive acceptance criteria, create follow-up tasks, and inspect task state. They rely on concise human-readable output and the `monitor` observer for project overview.