The --force flag is gone. Commands no longer have a backdoor to bypass WIP limits or steal claims — instead, each concern has its own explicit flag with clear semantics.
Changed: --force removed from move, edit, and delete
The --force flag conflated three unrelated concerns: bypassing WIP limits, overriding active claims, and confirming destructive deletes. This release replaces it with purpose-specific alternatives:
| Old usage | New approach |
|---|---|
move ID STATUS --force (bypass WIP)
| Raise WIP limits in config, or use bypass_column_wip: true on expedite class
|
edit ID --release --force (release someone else's claim)
| edit ID --release (no flag needed — release always works)
|
delete ID --force (confirm delete)
| delete ID --yes (or -y)
|
# Release a claim (no --force needed)
kanban-md edit 42 --release
# Confirm a delete
kanban-md delete 42 --yes
# WIP violations are now always errors — adjust limits in config.yml
Changed: WIP limit violations are always errors
Previously, --force could downgrade a WIP limit violation to a warning. Now WIP violations always fail. To work around them:
- Raise the limit: edit
wip_limitsinconfig.yml - Use expedite class: set
bypass_column_wip: trueon a priority class - Complete existing work before starting new items
Upgrading
If you have scripts or aliases using --force:
- Replace
delete --force/delete -fwithdelete --yes/delete -y - Replace
edit --release --forcewithedit --release - Remove
--forcefrommovecommands — WIP violations must be resolved through config
Full diff: v0.25.0...v0.26.0