feat(system): use last 2 folder layers for project name

[AnnatarHe]

Summary

• Updated get_project_name() to return last 2 folder layers instead of just 1
• Improves project identification when multiple projects have similar subfolder names (e.g., "frontend", "backend")
• Example: /code/malamtime/coding-extension-vim now returns malamtime/coding-extension-vim instead of just coding-extension-vim
• Updated tests to reflect new behavior

Test plan

• Run tests with ./scripts/test.sh
• Verify heartbeat data shows the last 2 folder layers in project field
• Test on paths with fewer than 2 layers to verify fallback works

🤖 Generated with Claude Code

[gemini-code-assist]

Summary of Changes

Hello @AnnatarHe, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request refines the system's project naming logic by extending the get_project_name function to capture the last two directory segments of a project's root path. This change aims to provide more distinct and informative project identifiers, mitigating potential naming collisions and improving clarity when dealing with projects that might otherwise have identical single-layer names. The update ensures that project tracking and display are more robust and user-friendly.

Highlights

• Enhanced Project Naming: The get_project_name function has been updated to extract the last two folder layers from a given path, rather than just the immediate directory name.
• Improved Project Identification: This enhancement improves project identification, especially in scenarios where multiple projects might share common single-layer names like 'frontend' or 'backend', providing more unique identifiers.
• Updated Test Coverage: Existing unit tests for get_project_name have been modified to validate the new two-layer naming convention and ensure correct behavior, including handling paths with fewer than two layers.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request updates the get_project_name function to return the last two directory layers of a path, which is a great improvement for project identification. The implementation logic is sound and handles various path structures correctly. The tests have been updated accordingly, but I've identified a test case that has become brittle due to its dependency on the test execution environment. I've provided a suggestion to improve the test's robustness. Overall, this is a solid feature enhancement.

[gemini-code-assist]

This assertion makes the test brittle because it depends on the environment where the tests are run. For example, if the project is located in a root directory like /my-project, get_project_name will correctly return my-project, but this assertion will fail because the name does not contain a /.

Test cases should be deterministic. I recommend removing this check and refactoring the parent test it('should handle current project', ...) to use hardcoded paths that cover specific scenarios. For example, you could add new tests for paths like /foo/bar and the root path /.

[claude]

Code Review

Summary

This PR improves project identification by using the last 2 folder layers instead of just 1. The implementation is clean and the tests are updated appropriately.

Strengths

1. Good motivation - Addresses a real UX issue where projects with common subfolder names would be indistinguishable
2. Simple implementation - The code is straightforward and easy to understand
3. Test coverage - Tests updated to reflect new behavior with good edge case coverage
4. Documentation - Function docstring updated to reflect the change

Potential Issues

1. Windows compatibility concern (lua/shelltime/utils/system.lua:89)

The current implementation checks parent != '/' which works for Unix paths, but on Windows, the root could be C:\ or other drive letters. This may cause incorrect behavior on Windows.

2. Trailing slash handling (lua/shelltime/utils/system.lua:87-88)

If project_root has a trailing slash, the behavior might be unexpected. While fnamemodify typically handles this, it is worth testing.

3. Edge case: Root directory projects (tests/system_spec.lua:200)

The test assertion assumes all project paths will contain a slash. This would fail if the current project is only one level deep. Consider making it conditional or removing it.

Suggestions

Performance: The implementation is fine - fnamemodify is efficient and this function is not called frequently.

Code Quality: Consider extracting the root detection logic to improve testability and Windows compatibility.

Security: No security concerns identified.

Test Coverage: Good overall. Suggested additions:

• Test with trailing slashes
• Test Windows-style paths (if supporting Windows)
• Make the test at line 200 more robust or conditional

Overall Assessment

Recommendation: Approve with minor changes

The PR is well-implemented and solves a real problem. The main concerns are:

1. Windows compatibility (if relevant to your user base)
2. One overly strict test assertion at line 200

The core logic is sound and follows the project coding conventions well. Nice work!

---

Review generated by Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.