feat(project): author the planning-suite mission for taskfiles (#262)

project/features/reusable-taskfile-adoption.md

@@ -0,0 +1,65 @@
+---
+id: F-1
+title: Reusable-Taskfile adoption
+status: done
+roadmap_item: R-1
+sprint: 1
+created: 2026-07-02
+ended: 2026-07-02
+verifies_sprint_value: acceptance-1
+consistency_check:
+  performed_at: 2026-07-02
+  agent_version: manual-fallback (retroactive; feature-consistency-reviewer not run cross-repo)
+  findings:
+    - kind: clean
+      target: project/features/
+      resolution: proceed
+      evidence: "project/features/ empty (first decomposition); no feature-to-feature overlap possible."
+    - kind: prior-art
+      target: src/taskfile-include-mkdocs.yaml
+      resolution: proceed
+      evidence: "The src/taskfile-include-*.yaml module collection already exists and is consumed portfolio-wide; F-1 documents the shipped adoption contract, it does not build new modules."
+---
+
+## Description
+
+F-1 is the mission-verifying feature for `taskfiles`' shipped minimum viable
+product. It captures the adoption contract of the reusable `Taskfile` module
+collection (R-1). A downstream `nolte/*` project adopts a module by including it
+remotely through `TASK_COLLECTION_BASE`. The contract holds when the include
+resolves and the consumer's task target runs green. This already holds across
+the portfolio, because sibling repositories wire these modules and run their
+targets. The retroactive reconciliation therefore records this feature as `done`
+(issue `nolte/claude-shared#262`).
+
+## Acceptance criteria
+
+- [x] **acceptance-1** A downstream `nolte/*` project includes a
+  `taskfile-include-*.yaml` module remotely through `TASK_COLLECTION_BASE` and its
+  task target runs green. _(This is the sprint value verifier.)_
+- [x] **acceptance-2** Every task honours the `dir: '{{.USER_WORKING_DIR}}'`
+  invariant, so commands run in the consumer's working directory.
+- [x] **acceptance-3** Per-module task signatures stay stable across tags, so
+  existing consumer pins keep resolving.
+
+## Test hooks
+
+- **acceptance-1**: a sibling repository's Taskfile that includes a module and
+  runs its target shows this; passing.
+- **acceptance-2**: manual review of each `src/taskfile-include-*.yaml` module for
+  the `dir` invariant; passing.
+- **acceptance-3**: manual review of the tag and signature convention; passing.
+
+## Consistency notes
+
+This is a retroactive documentation feature. The underlying capability
+(`reusable-taskfile-collection`) predates the planning suite. This feature
+introduces no new implementation. It exists so the mission's
+`verifies_via: F-1:acceptance-1` and sprint 1's `value_statement` resolve to a
+real acceptance criterion.
+
+## References
+
+- `project/portfolio.yml` capability `reusable-taskfile-collection`
+- `AUDIENCES.md` audience "Taskfile-consumer project"
+- `README.md` module table (the published `src/taskfile-include-*.yaml` catalogue)

project/goals.md

@@ -0,0 +1,24 @@
+# Vision
+
+`taskfiles` is the `nolte` portfolio's single source of reusable `Taskfile`
+include modules. Each module ships as one YAML file under `src/`. Downstream
+`nolte/*` projects wire a module remotely through `Taskfile`'s `remote-taskfiles`
+experiment, pointing `TASK_COLLECTION_BASE` at the collection. There's no build
+step and no runtime artefact. The YAML files are the product. Every task sets
+`dir: '{{.USER_WORKING_DIR}}'`, so commands run in the consumer's working
+directory.
+
+## Outcomes
+
+- **O-1**: downstream projects get consistent task targets by including
+  `taskfiles`' reusable modules remotely instead of copying `Taskfile` logic into
+  each repository. _(audience: Taskfile-consumer project)_
+- **O-2**: consumer-side developers run predictable, idempotent task commands
+  locally in their own working directory. _(audience: Consumer-side developer
+  running tasks locally)_
+- **O-3**: consumer-side CI/CD pipelines invoke the same task targets as local
+  runs, so local and CI behaviour stay identical. _(audience: Consumer-side CI/CD
+  pipeline)_
+- **O-4**: the maintainer evolves the module collection with stable task
+  signatures and tag stability, so consumer pins stay stable across changes.
+  _(audience: Module maintainer)_

project/mission.md

@@ -0,0 +1,77 @@
+---
+mission_statement: "Taskfiles gives downstream nolte/* projects one centralised, remotely included collection of reusable Taskfile modules, so they get consistent task targets across local and CI runs without copying Taskfile logic into each repository."
+relevant_outcomes: [O-1, O-2, O-3, O-4]
+audiences:
+  - Taskfile-consumer project
+  - Consumer-side developer running tasks locally
+  - Consumer-side CI/CD pipeline
+  - Module maintainer
+verifies_via: F-1:acceptance-1
+time_bound:
+  kind: mvp_completion
+mvp_status: achieved
+created: 2026-07-02
+revised_at: null
+---
+
+## Statement
+
+`taskfiles` gives downstream `nolte/*` projects one centralised,
+remotely included collection of reusable `Taskfile` modules. They get consistent
+task targets across local and CI runs without copying `Taskfile` logic into each
+repository.
+
+- **Specific**: the statement names *what* (a remotely included collection of
+  reusable `Taskfile` modules) and *for whom* (the consumer audiences plus the
+  module maintainer, resolved in `audiences`).
+- **Measurable**: `verifies_via: F-1:acceptance-1`. F-1's acceptance criterion 1
+  measures the mission. A consumer project includes a module remotely and its
+  task target runs green.
+- **Achievable**: the minimum viable product is the shipped
+  `reusable-taskfile-collection` capability. Roadmap item R-1 carries `mvp:
+  true`, `detail: fine`, and `target_sprint: 1`.
+- **Relevant**: `relevant_outcomes: [O-1, O-2, O-3, O-4]`. Each entry resolves to
+  an outcome in `project/goals.md`.
+- **Time-bound**: `time_bound: { kind: mvp_completion }`. The bound is the moment
+  the shipped minimum viable product reaches achieved status, not a calendar
+  date.
+
+## Audiences
+
+- **Taskfile-consumer project**: the minimum viable product delivers a collection
+  of `src/taskfile-include-*.yaml` modules that a project wires in remotely
+  through `TASK_COLLECTION_BASE`. The project gets stable per-module task
+  signatures without copying `Taskfile` logic.
+- **Consumer-side developer running tasks locally**: the minimum viable product
+  delivers predictable, idempotent task commands. A developer runs
+  `task <module>:<task>` in their own working directory, honoured by the
+  `dir: '{{.USER_WORKING_DIR}}'` invariant.
+- **Consumer-side CI/CD pipeline**: the minimum viable product delivers the same
+  task targets that developers run locally. A pipeline invokes them, so local and
+  CI behaviour stay identical.
+- **Module maintainer**: the minimum viable product delivers a single place to
+  evolve the module collection. Stable task signatures and tag stability keep
+  consumer pins stable when the collection changes.
+
+## Verification
+
+Feature **F-1: Reusable-Taskfile adoption** verifies the mission through
+acceptance criterion 1: *"A downstream `nolte/*` project includes a
+`taskfile-include-*.yaml` module remotely through `TASK_COLLECTION_BASE` and its
+task target runs green."* This is the `verifies_sprint_value` criterion for
+sprint 0001. It already holds across the portfolio, because sibling repositories
+wire these modules and run their targets. The mission therefore records the
+shipped minimum viable product as `achieved`.
+
+## Source
+
+- **Audience artefact**: `AUDIENCES.md` at the `taskfiles` repository root,
+  consulted at its current develop tip. The four `audiences` entries are the
+  three primary direct-consumer and operator audiences plus the module
+  maintainer.
+- **Outcomes referenced**: O-1, O-2, O-3, O-4 from `project/goals.md`.
+- **Authored by**: the `mission-define` cascade (issue `nolte/claude-shared#262`
+  mission-authoring backfill), 2026-07-02. The cascade models the minimum viable
+  product retroactively. `taskfiles`' capability already carried `status: active`
+  when the repository adopted the planning suite, so the roadmap records R-1 as
+  `status: done` and opens `mvp_status` at `achieved` rather than `defining`.

project/roadmap.md

@@ -0,0 +1,38 @@
+# Roadmap
+
+This file is the work queue governed by `spec/project/roadmap/`. Each entry is a
+level-3 heading followed by a `yaml` code block (`id`, `title`, `detail`,
+`outcomes`, `target_sprint`, `mvp`, `status`, in that order) and a free-text
+body. `roadmap-plan` and `roadmap-refine` own the detail level (`detail`: `fine`
+/ `coarse` / `backlog`) and the status lifecycle (`status`: `proposed`,
+`active`, `done`, plus `cancelled`). Don't hand-edit those fields here.
+
+Entries carry monotonically increasing IDs starting at `R-1`, never reused.
+Outcome IDs (`O-n` in `goals.md`) are an independent counter. The two streams
+never cross.
+
+`taskfiles` shipped the minimum-viable-product item below before adopting the
+planning suite, because it's a mature, portfolio-wide configuration source. This
+roadmap records it retroactively as `status: done`, mapped to sprint 1, so the
+mission's minimum viable product resolves. See `project/mission.md` §Source.
+
+## Phase 1: Shared task-target baseline
+
+### R-1: Reusable Taskfile include collection
+
+```yaml
+id: R-1
+title: Reusable Taskfile include collection
+detail: fine
+outcomes: [O-1, O-2, O-3]
+target_sprint: 1
+mvp: true
+status: done
+```
+
+The `src/taskfile-include-*.yaml` module collection covers `mkdocs`,
+`pre-commit`, `kind`, `k8s`, and `worktree` task targets. Downstream `nolte/*`
+projects include a module remotely by pointing `TASK_COLLECTION_BASE` at the
+collection. Every task honours the `dir: '{{.USER_WORKING_DIR}}'` invariant, so
+commands run in the consumer's directory. Capability
+`reusable-taskfile-collection` in `project/portfolio.yml`.

project/sprints/0001-shared-task-baseline.md

@@ -0,0 +1,40 @@
+---
+number: 1
+status: closed
+started: 2026-07-02
+ended: 2026-07-02
+value_statement: Downstream nolte/* projects include the reusable Taskfile modules remotely and get consistent task targets across local and CI runs without copying Taskfile logic.
+artifact_ref: develop (shipped capability, pre-planning-suite)
+roadmap_items: [R-1]
+features: [F-1]
+---
+
+## Goal
+
+Downstream `nolte/*` projects obtain consistent task targets from one
+centralised, remotely included collection of reusable `Taskfile` modules. The
+consumer no longer copies `Taskfile` logic into each repository. F-1
+`acceptance-1` verifies success: a consumer project includes a module remotely
+through `TASK_COLLECTION_BASE` and its task target runs green.
+
+## Features
+
+- [F-1](../features/reusable-taskfile-adoption.md): Reusable-Taskfile adoption, status: done
+
+## Out of scope
+
+- Pinning concrete consumer identities and pin strategies. `AUDIENCES.md` tracks
+  these as open questions, outside the shipped scope.
+- The wrapped tools themselves (`kind`, `mkdocs`, `kubectl`, `helm`,
+  `pre-commit`, ArgoCD), which sit outside the bounded context.
+
+## Review notes
+
+Retroactive reconciliation (2026-07-02): `taskfiles`' `reusable-taskfile-collection`
+capability already carried `status: active` and served the portfolio before this
+repository adopted the planning suite (issue `nolte/claude-shared#262`
+mission-authoring backfill). This sprint therefore records roadmap item R-1 and
+feature F-1 as `done`, and itself as `closed`. That documents the delivered
+minimum viable product rather than new planned work. The value verifier F-1
+`acceptance-1` already holds: sibling repositories wire these modules and run
+their task targets.