Enum ProjectCommand 

pub enum ProjectCommand {
    Create {
        name: String,
        description: Option<String>,
        status: Option<String>,
        lead: Option<String>,
        start_date: Option<String>,
        due_date: Option<String>,
    },
    Edit {
        reference: String,
        name: Option<String>,
        description: Option<String>,
        status: Option<String>,
        lead: Option<String>,
        start_date: Option<String>,
        due_date: Option<String>,
    },
    List,
    Show {
        reference: String,
    },
    Delete {
        reference: String,
        yes: bool,
    },
    Add {
        reference: String,
        issues: Vec<String>,
    },
    Remove {
        reference: String,
        issues: Vec<String>,
    },
    BulkAdd {
        reference: String,
        issues: Vec<String>,
    },
}

The tix project subcommands (mission first-class-projects-01M3BYBW, WP05).

A required subcommand, like tix milestone and tix cycle: tix project alone is a usage error, not a listing, because guessing which of ten verbs the user meant is worse than asking.

Selection is by the stable id (the registry key); a name is accepted as a convenience and resolves to the same project, since tix.toml guarantees the names are unique.

Variants

Create

Create a project and allocate a stable id

The name is a display label, not the identity: it can be changed later with tix project edit --name, and every issue association survives because the issues reference the id.

Fields

name: String

Display name (unique within the registry, case-insensitively)

description: Option<String>

Long-form context

status: Option<String>

Free-form project status (not a board column)

lead: Option<String>

Lead identity string

start_date: Option<String>

Start date (YYYY-MM-DD)

due_date: Option<String>

Due date (YYYY-MM-DD); must be >= start-date

Edit

Edit a project’s fields; a rename changes the label only

Nothing is re-keyed: the id stays, so every association and every derived figure is untouched. An optional text flag with a blank value clears it (--lead ""), the same convention tix edit uses.

Fields

reference: String

Project id (a name is accepted as a convenience)

name: Option<String>

New display name

description: Option<String>

New long-form context (--description "" clears)

status: Option<String>

New free-form status (--status "" clears)

lead: Option<String>

New lead identity string (--lead "" clears)

start_date: Option<String>

New start date (YYYY-MM-DD; --start-date "" clears)

due_date: Option<String>

New due date (YYYY-MM-DD; --due-date "" clears)

List

List projects in declaration order, with ids and member counts

Show

Show one project’s record and its members

Fields

reference: String

Project id (a name is accepted as a convenience)

Delete

Delete a project’s registry entry (its issues are never deleted)

The issues that referenced the project keep their references; the report names them so the dangling references can be repaired deliberately.

Fields

reference: String

Project id (a name is accepted as a convenience)

yes: bool

Confirm without prompting

Add

Associate one or more issues with a project

Each selector is processed independently: a rejection on one is reported and does not abort the rest.

Fields

reference: String

Project id (a name is accepted as a convenience)

issues: Vec<String>

Issue numbers, filename fragments or unique title fragments

Remove

Dissociate one or more issues from a project

Drops only the association; no issue is deleted, and each selector is processed independently.

A reference that does not name a live project is used verbatim, because removing a retained stale id is the repair path a project deletion leaves open (C-005). A typo that matches nothing is therefore an inert no-op that reports 0 changed, not a refusal — which is the one place this differs from tix edit <issue> --remove-project <id>, where an unknown reference the issue does not carry is refused as unknown_project.

Fields

reference: String

Project id (a name is accepted as a convenience)

issues: Vec<String>

Issue numbers, filename fragments or unique title fragments

BulkAdd

Bulk-associate one or more issues with a project

Project association only — general bulk editing is a different feature. Every selector is processed independently and every outcome is reported, so one unknown selector does not discard the associations that succeeded.

An unknown project reference refuses the whole command before anything is written (all entries then fail with unknown_project); use tix project remove to drop a retained stale id, whose reference is matched verbatim and reported as 0 changed rather than refused.

Fields

reference: String

Project id (a name is accepted as a convenience)

issues: Vec<String>

Issue numbers, filename fragments or unique title fragments

Trait Implementations

impl FromArgMatches for ProjectCommand

fn from_arg_matches(__clap_arg_matches: &ArgMatches) -> Result<Self, Error>

Instantiate Self from ArgMatches, parsing the arguments as needed.

fn from_arg_matches_mut( __clap_arg_matches: &mut ArgMatches, ) -> Result<Self, Error>

Instantiate Self from ArgMatches, parsing the arguments as needed.

fn update_from_arg_matches( &mut self, __clap_arg_matches: &ArgMatches, ) -> Result<(), Error>

Assign values from ArgMatches to self.

fn update_from_arg_matches_mut<'b>( &mut self, __clap_arg_matches: &mut ArgMatches, ) -> Result<(), Error>

Assign values from ArgMatches to self.

impl Subcommand for ProjectCommand

fn augment_subcommands<'b>(__clap_app: Command) -> Command

Append to Command so it can instantiate Self via FromArgMatches::from_arg_matches_mut

fn augment_subcommands_for_update<'b>(__clap_app: Command) -> Command

Append to Command so it can instantiate self via FromArgMatches::update_from_arg_matches_mut

fn has_subcommand(__clap_name: &str) -> bool

Test whether Self can parse a specific subcommand