feat: expand automatic cwd project context#25
Conversation
Why: - Cargo.lock on main still records workspace crate package versions as 0.1.0. - Running the current Rust test suite refreshes those entries automatically, so the lockfile drifts on every Rust feature branch. What: - update workspace crate version metadata in Cargo.lock from 0.1.0 to 0.2.0 Tests: - cargo test -p app -p api -p forge Risk: - low; no dependency graph change, only workspace package metadata refresh.
Why: - Forge already resolves linked projects from cwd, but the current logic only matches raw path ancestry. - Developer tooling should behave like Git and Cargo by normalizing to the repo root first, then falling back to linked paths when needed. What: - change project resolution to prefer a git repo root match before raw cwd ancestry - preserve raw linked-path fallback when the repo root itself is not linked - add service regression tests for git-root precedence and fallback behavior Tests: - cargo test -p app -p api -p forge Risk: - medium; this changes project-context precedence, but it is covered by service tests for both the preferred and fallback paths.
Why: Forge already had linked workdirs, but several CLI flows still required explicit project selection even when the current working directory identified the active project. What: Apply cwd-based project inference to task and event listing, focus set, contextual project status, and today output; add --all escape hatches for contextual list defaults and clear errors when context is required but missing. Tests: cargo test -p app -p api -p forge Risk: Moderate; list defaults now become contextual inside linked workdirs, but explicit project selectors still win and --all preserves global behavior.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 1c746868e4
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if let Some(git_root) = resolve_git_root(&resolved_cwd) { | ||
| if let Some(project) = match_project_for_path(&project_list, &git_root) { |
There was a problem hiding this comment.
If a user links both a broad parent directory and a deeper folder inside a repo, this early return resolves the parent project instead of the deeper one. match_project_for_path(&project_list, &git_root) accepts any ancestor of the repo root, so with links like /work and /work/repo/backend, a cwd of /work/repo/backend/src now resolves to /work and never reaches the raw-cwd fallback. That makes every cwd-inferred command built on resolve_project_by_path (task add, event add, focus set, etc.) attach to the wrong project whenever the repo sits under another linked project.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed in 39d7a9f. The git-root fast path now requires an exact project workdir match instead of accepting broad ancestors, and I added a regression test covering a linked workspace parent plus a deeper linked repo subdirectory under one git root.
| let current_project = if args.project.is_none() && !args.all { | ||
| api.resolve_project_from_cwd().await? |
There was a problem hiding this comment.
--task as an explicit scope for event list
When forge event list --task <id> is run from inside any linked project, this branch still auto-infers project_id from the cwd and combines it with linked_task_id. That is too restrictive because events are allowed to link to a task without sharing its project (see create_event, which only validates that the IDs exist), so listing an inbox task's blocks or a task from another project now silently returns nothing unless the user also knows to add --all. --task is already an explicit selector and should not be narrowed by cwd context.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed in c8e3386. forge event list --task <id> now counts as an explicit scope and skips cwd-based project inference, with a regression test covering the inference guard so task-scoped listings stay global unless the user also passes an explicit project filter.
Why: Git-root preference could resolve a broad parent workdir before a more specific linked subdirectory inside the same repository. What: Restrict the git-root fast path to exact root matches and add a regression test covering overlapping parent and nested links under one repo. Tests: cargo test -p app -p forge Risk: Low; only cwd path resolution changes, and raw-path fallback still handles nested links.
Why: orge event list --task <id> was still inheriting cwd project context, which could hide events for inbox or cross-project linked tasks. What: Treat --task as an explicit scope for event listing and add regression coverage for the inference guard. Tests: cargo test -p app -p forge Risk: Low; only event list context inference changes, and explicit project or --all behavior stays intact.
1 participant
Summary
Testing
Closes #24