Work

.github/prompts/implement-task.prompt.md

@@ -28,12 +28,11 @@ Guidelines:
 - Priorities: P0 (urgent) → P3 (low).
 - Categories: bug | feat | fix | idea | human.
 - Flags (optional): CLARIFICATION, HUMAN INPUT, HUMAN TASK, DUPLICATE.
-- Version flags (optional): V1, V2 etc. (used to group versions/releases).
 - Mark completion by [ ] → [X]. Keep changes atomic (one commit per task).
 - Mark won't-do tasks by [ ] → [-] and add `WONT DO` to Flags.
 
 ## Example
-- [ ] T001 P1 feat - Initial placeholder task (Flags: CLARIFICATION, V1)
+- [ ] T001 P1 feat - Initial placeholder task (Flags: CLARIFICATION)
 
 ## UNCATEGORIZED
 - Add brand new tasks here before categorization (human or agent). The agent MUST first review this section before selecting any other task. For each uncategorized task: assign an ID (T###), priority, category, and flags; then move it into the proper thematic section; finally REMOVE it from UNCATEGORIZED.
@@ -73,16 +72,34 @@ Produce a concise bullet plan:
 - Goal & acceptance criteria (derived + user clarifications)
 - Constitution / architectural principle alignment (reference sections if available)
 - Files to change (relative paths)
-- Minimal diff strategy (why changes are smallest possible)
-- Test approach (existing tests, new tests only if essential)
+- Design quality check: assess whether the existing code structure is a good
+  fit for this change. If the area is fragile, duplicated, or poorly abstracted,
+  identify the specific problem and propose one or more preparatory refactoring
+  tasks (with suggested category and title). Ask the user whether to add them to
+  TASKS.md and tackle them first, or proceed with the current task as-is. Do NOT
+  add tasks to TASKS.md without explicit user approval.
+- Scope: implement the smallest change that is also correct and does not make
+  the design worse. A prior refactor commit that makes the actual change cleaner
+  is in scope; unrelated cleanup is not.
+- Test approach:
+  - **Bug tasks**: prefer TDD — write a failing test first that demonstrates the
+    bug, commit it separately, then implement the fix. The test commit message
+    should be prefixed with `test:` and reference the task title. Only skip
+    the failing-test commit if the bug cannot be exercised by an automated test.
+  - **Feat/fix tasks**: new tests only if essential.
 - Risks & rollback steps
 Wait for user APPROVAL. Stop if not approved.
 
 ### 5. Implement
 After approval:
+- **Bug tasks (TDD)**: before writing the fix, write a failing test that
+  reproduces the bug and commit it alone (prefix: `test:`). Then implement the
+  fix in a subsequent commit and confirm the test now passes.
 - Apply smallest possible, atomic changes (optimize for a single concise commit per task).
+- If a preparatory refactor was identified in the plan, commit it separately
+  before the main change.
 - If task inherently requires multiple steps, propose splitting before proceeding.
-- Avoid unrelated refactors.
+- Avoid unrelated cleanup (out-of-scope refactors belong in their own task).
 - Keep shared/domain logic host-neutral (follow project conventions, e.g. packages/, libs/, src/domain/).
 - No new dependencies unless explicitly approved.
 - No secrets or credentials added.

.github/workflows/rust.yml

@@ -20,6 +20,10 @@ jobs:
       run: cargo fmt --all -- --check --verbose
     - name: Clippy
       run: cargo clippy --all-targets -- -D warnings --verbose
+    - name: Licenses
+      uses: EmbarkStudios/cargo-deny-action@v2
+      with:
+        command: check licenses
     - name: Build
       run: cargo build --all-targets --verbose
     - name: Run tests

CHANGELOG.md

@@ -5,10 +5,47 @@ All notable changes to this project will be documented in this file.
 The format is based on
 [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
 
+
 ## [Unreleased]
 
 ### Added
 
+- `<BASE>` argument is now optional. When omitted, `gt` resolves `origin/HEAD`
+  to determine the repository's default upstream branch (e.g. `origin/main`).
+  Falls back to `main` if `origin/HEAD` is not configured.
+- Press `e` in the conflict dialog to open each conflicting file directly in the
+  configured editor (`GIT_EDITOR` → `core.editor` → `$VISUAL` → `$EDITOR` →
+  `vi`). After the editor exits the conflict state is refreshed, the same way
+  the mergetool (`m`) path works.
+
+### Fixed
+
+- Fixup operations that hit a squash-tree conflict no longer open the commit
+  message editor after the conflict is resolved — the target commit's message is
+  used as-is, matching the behavior of a conflict-free fixup.
+- Resolving a conflict that involves a deleted or renamed file (modify/delete
+  conflict) is no longer falsely reported as still unresolved: `stage_file` now
+  correctly stages the deletion when the file is absent from the working tree
+  instead of failing with "file not found".
+- Aborting a squash or fixup after a conflict now correctly leaves a clean
+  working tree: `checkout_head` (force) already resets both the index and
+  workdir to HEAD, including removing any files written during conflict checkout
+  that are absent from HEAD's tree.
+- Conflicts resolved in an external editor (e.g. VS Code) are now detected when
+  pressing Enter to continue: the app auto-stages working-tree files whose
+  conflict markers have been removed, so the index reflects the actual
+  resolution state. Previously only the built-in mergetool path worked.
+- Fragmap now tracks file renames across commits: when a file is renamed,
+  overlapping spans in the old and new paths are correctly clustered together
+  instead of being treated as unrelated files.
+- Added possibility to perform drop, move and squash operations when there are
+  unstaged/staged changes in a submodule.
+
+
+## [0.1.0] - 2026-03-15
+
+### Added
+
 - Interactive TUI commit browser showing all commits between HEAD and the
   merge-base with a configured base branch (e.g. `main`).
 - Hunk group matrix panel: a fragmap-style visualization showing which commits

README.md

@@ -31,7 +31,7 @@ Requires Rust 1.85 or later.
 ## Usage
 
 ```sh
-gt <base>
+gt [base]
 ```
 
 `<base>` identifies the branch or point you forked from — typically the target
@@ -40,10 +40,15 @@ be a direct ancestor of `HEAD`: the **merge-base** (common ancestor) between
 `<base>` and `HEAD` is used as the reference point. All commits between that
 merge-base and `HEAD` are shown.
 
+When `<base>` is omitted, `gt` automatically uses the repository's default
+upstream branch by resolving `origin/HEAD`. If that is not configured it falls
+back to `main`.
+
 ```sh
 gt main              # commits on top of main
 gt origin/main       # commits not yet pushed
 gt v1.2.3            # commits since a tag
+gt                   # auto-detect default branch (origin/HEAD or main)
 ```
 
 **Flags:**