祝融说。

33.1 Kanban-Driven Work: Make Progress Visible, Status Traceable

Kanban is the foundational infrastructure for high-autonomy team collaboration. Its core value: make progress visible, make status traceable.

In a high-autonomy environment, no one is watching over your progress from behind. Kanban replaces the "supervisor" and becomes the team's shared "progress dashboard" -- everyone can see at any time: what the team is working on, who is doing what, which tasks are blocked, and which tasks are done.

The basic Kanban columns: Todo → In Progress → Review/Test → Done. On top of these, a team can add a "Blocked" column as needed (for tasks that hit an obstacle and cannot move forward).

The basic principles of Kanban-driven work:

1. All work goes on the board: every piece of work (feature development, bug fixes, technical debt cleanup, design tasks) should have a corresponding card on the board. A task without a card is a task that does not exist.
2. Status must reflect reality: a card's status must truthfully reflect the actual state of the work -- drag it into "In Progress" when you start, into "Done" when you finish, and mark it "Blocked" with a reason when it is stuck.
3. WIP limit (Work In Progress Limit): cap the number of in-progress tasks in each column to prevent "multi-tasking hell" -- doing too many things at once means doing none of them well.
4. The board is communication: progress sync does not require repeated "status reports"; the board itself is the most truthful progress report.

33.2 The Art of Labels: Quickly Aligning Context

As task cards multiply, labels (Label/Tag) become a powerful tool for quickly classifying, filtering, and aligning context.

Common label dimensions:

• Priority: P0 (handle immediately, urgent incident), P1 (high priority, complete soon), P2 (normal priority), P3 (low priority, can wait);
• Type: feature (new functionality), bug (defect), chore (housekeeping), refactor (refactoring), tech-debt (technical debt);
• Business domain: auth (authentication), payment (payment), checkout (checkout), user (user);
• Status semantics: blocked (blocked), needs-review (awaiting review), urgent (urgent), money (involves money, high risk).

The value of labels: a card labeled urgent + money + payment lets anyone who sees it immediately judge -- this is an urgent, money-involving payment task that needs priority handling. Labels turn "context alignment" from "reading each card description one by one" into "scanning the label bar in one glance."

Label discipline: the label system requires a shared team agreement and consistency. Do not overuse labels (too many labels is the same as none), and periodically clean up labels that are no longer used.

33.3 Task Ownership and Follow-Through: Who Initiates, Who Clarifies, Who Closes

A task's journey from "idea" to "archive" requires clear answers to three questions: who initiates, who clarifies, and who closes.

• Who initiates (Initiator): the creator of the task. They are responsible for turning the idea into a clear task card (including background, goals, and acceptance criteria);
• Who clarifies (Clarifier): usually also the creator. When the implementer has questions about the task, they are responsible for clarifying the requirements, supplementing context, and resolving disagreements;
• Who closes (Closer): the implementer. They are responsible for completing the task and updating its status, while the creator is responsible for acceptance confirmation. Only a task that has been confirmed through acceptance can be marked "Done."

Practical guidelines for ownership and follow-through:

1. One task, one owner: every task card must have a clear Assignee (implementer). Tasks with "no one responsible" are not allowed.
2. The initiator follows through to the end: the task creator is responsible for tracking the task's progress until closure -- they cannot "create the card and disappear."
3. Blockages must be reported: when a task is blocked, the implementer must immediately note the reason, impact, and help needed on the card, rather than waiting silently.

33.4 Branch Management: One Task, One Branch

"One task, one branch" is a fundamental discipline of code collaboration. It ties every code change to a specific task card, making merges, reviews, and rollbacks clear and controllable.

Branch naming convention (conventional commits style recommended):

feature/[ticket-id]-[short-description]    # Feature development
fix/[ticket-id]-[short-description]        # Bug fix
hotfix/[ticket-id]-[short-description]     # Urgent production fix (branch from master)
chore/[ticket-id]-[short-description]      # Maintenance/build/tools
refactor/[ticket-id]-[short-description]   # Refactoring

Examples: feature/TICKET-123-user-tagging, fix/TICKET-789-null-pointer-on-profile.

Branch discipline:

1. One task, one branch: create the branch from the main development line (develop/master), matching it one-to-one with the task, and delete the branch after the task is completed and merged;
2. Create branches from the correct main line: normal features branch from develop; production hotfixes must branch from master (the branch that represents production code) -- because develop may contain other unreleased, unstable new features, and you do not want to drag unrelated risky changes into a hotfix;
3. Small, incremental commits: keep commits within a branch small and clear; each commit tells one story (see 33.5);
4. Pass review before merging: before a branch merges into the main line, it must pass CI checks plus code review (one task, one branch naturally focuses the scope of the review).

33.5 Commit Management: Let Every Commit Tell a Clear Story (Conventional Commits)

A commit is the "written record" of team collaboration -- it is the smallest unit of code history and a projection of team culture onto the codebase. A team's commit history should read like a well-structured diary, not a tangled mess.

Conventional Commits is a standardized specification for commit messages:

<type>(<scope>): <subject>

<body> (optional)

<footer> (optional, e.g. BREAKING CHANGE: ...)

Type categories:

The value of Conventional Commits:

1. Make history readable: anyone scanning git log can quickly understand the intent of each commit -- does it add a feature, fix a bug, or refactor?
2. Automated Changelog generation: based on commit types, a clear version change log can be generated automatically;
3. Enable automation: semantic version numbers can be computed automatically from commit types (feat bumps minor, fix bumps patch, BREAKING CHANGE bumps major).

Good commits vs. bad commits:

❌ Poor commits: `fix stuff` / `update` / `changes`
✅ Good commit: `fix(payment): fix duplicate charges from concurrent orders`

❌ Poor commit (mixing several changes): `add auth and fix bugs and refactor user service`
✅ Good commit (one story per commit): `feat(auth): add JWT refresh tokens`

33.6 Releases and Changelog: Semantic Versioning

Semantic Versioning (SemVer) is the standard specification for version numbers, in the format MAJOR.MINOR.PATCH:

• MAJOR (major version): incremented on incompatible API changes (e.g., 1.0.0 → 2.0.0);
• MINOR (minor version): incremented when backward-compatible features are added (e.g., 1.0.0 → 1.1.0);
• PATCH (patch version): incremented on backward-compatible bug fixes (e.g., 1.0.0 → 1.0.1).

The value of Semantic Versioning: it communicates the "risk level" of a change to everyone (including other teams that depend on your system) -- seeing a MAJOR version change, you know there may be incompatible changes; seeing a PATCH change, you know it is a safe fix.

The Changelog is the "internal sync and external announcement" of a release:

• Internally: team members use the Changelog to understand what each release contains and quickly pinpoint "which version fixed this bug";
• Externally: downstream dependents use the Changelog to assess upgrade risk and decide whether they need to adjust their code.

Changelog conventions:

## [2.1.0] - 2026-08-15
### Added
- Support phone-number login
### Fixed
- Fix lost payment orders
### Changed
- Upgrade dependency versions

Where the Changelog meets AI collaboration: remember chapters 13-14? CHANGELOG.md is the AI's "voyage log" -- it is how the AI restores context after every /clear. It is both a version record for humans and a "project state snapshot" for the AI. A well-formed Changelog serves two goals at once: "human collaboration" and "human-AI collaboration."

Release process (drawing on the canary-release SOP from chapter 24):

1. Merge all changes into develop and run the full test suite;
2. Update the Changelog, clearly stating the changes in this release;
3. Create a release branch and deploy to the canary environment for verification;
4. Once the canary passes (confirmed by two people), roll out to everyone;
5. Tag the release (e.g., v2.1.0) as a rollback baseline.

Part Ten complete. You have now mastered the complete system of team collaboration and delivery culture: asynchronous first, public by default (say goodbye to "are you there?", information-saturating communication, the value of public channels), high trust without monitoring (predictability matters more than capability, "everything gets a response," the first-message rule for bad news, the SBI-I difficult-conversation model), high autonomy and high-quality delivery (output-oriented rather than online-oriented, clear boundaries and a shared blueprint via OKR, from executor to owner, respect for production and data red lines, the 15-minute rule), and the task lifecycle and code as communication (Kanban-driven work, the art of labels, task ownership, one task one branch, Conventional Commits, Semantic Versioning and the Changelog).

Now, let us move on to Part Eleven: Team Onboarding and Continuous Evolution. There, the methodology will grow from one team's culture into a replicable onboarding roadmap and training system.