tix-tracker 0.12.0

A terminal issue tracker: markdown + YAML frontmatter issues with a kanban TUI and CLI
Documentation 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92

#[allow(clippy::wildcard_imports)]
use super::*;

/// The `tix triage` tree (`contracts/cli-surface.md`, WP05 T023–T025).
///
/// `list` and `status` are read-only queue views; the four decision verbs take a
/// single issue; `batch` is the selection-shaped twin of `tix bulk`, preview by
/// default and writing only under an explicit `--apply`.
///
/// ## Why the reason flag is `Option` on `accept` and the rest
///
/// `contracts/decision-history.md` splits it: decline, duplicate and defer
/// *require* a reason, accept records one when supplied. A required clap argument
/// on three of the four would make the fourth's absence look like an oversight,
/// and — more importantly — the enforcement belongs to the service, which refuses
/// `missing_reason` before any write on every surface (NFR-003). The flag is
/// therefore optional everywhere and the *rule* is the service's, so the CLI,
/// TUI and MCP cannot end up with three different ideas of which decision needs
/// one. `tix triage decline 1` with no `--reason` still fails, at the service,
/// with the contract's own kind.
/// `tix health`'s actions.
#[derive(Subcommand)]
pub enum HealthAction {
    /// Record an issue's health state (append-only; needs --rationale)
    ///
    /// Writes the frontmatter value and **one** History entry, together or not at
    /// all. Any of the four states is accepted; anything else is refused by name.
    Set {
        /// The issue, by number or slug
        issue: String,
        /// One of `unknown`, `on_track`, `needs_attention`, `at_risk`
        #[arg(long)]
        state: String,
        /// Who is making the change (defaults to the configured git identity)
        #[arg(long)]
        actor: Option<String>,
        /// When, as `YYYY-MM-DD` (defaults to today)
        #[arg(long)]
        date: Option<String>,
        /// Why — required: a health change nobody can explain is not recorded
        #[arg(long)]
        rationale: Option<String>,
    },
    /// Show one issue's health: its own value, its derived rollup, its diagnostics
    Show {
        /// The issue, by number or slug
        issue: String,
    },
    /// Show a scope's derived health, with its contributors and policy version
    Rollup {
        /// `issue` | `project` | `epic` | `cycle` | `milestone`
        #[arg(long)]
        scope: String,
        /// The scope's stable id (an issue number for `--scope issue`)
        #[arg(long)]
        id: String,
    },
    /// Layer an explicit override over a derived scope's health
    ///
    /// An override is a deliberate act about a whole scope, so it needs `--confirm`:
    /// it does not replace what the children say, it is recorded *over* it.
    Override {
        /// `project` | `epic` | `cycle` | `milestone`
        #[arg(long)]
        scope: String,
        /// The scope's stable id
        #[arg(long)]
        id: String,
        /// One of `unknown`, `on_track`, `needs_attention`, `at_risk`
        #[arg(long)]
        state: String,
        /// Who is making the change (defaults to the configured git identity)
        #[arg(long)]
        actor: Option<String>,
        /// When, as `YYYY-MM-DD` (defaults to today)
        #[arg(long)]
        date: Option<String>,
        /// Why — required
        #[arg(long)]
        rationale: Option<String>,
        /// Confirm an override of derived health
        #[arg(long)]
        confirm: bool,
    },
    /// The append-only health History entries about a scope
    History {
        /// A scope: `issue:42`, `cycle:2026-10`, `milestone:m1`, …
        scope: String,
    },
    /// Every scope's health, with what contributes to each
    Board,
}