Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

feat(projects): support canonicalizing a lone legacy project spelling without cloud sync

Closed
  • Is something wrong?
#1,682 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
45/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
go, sqlite
Domain
cli, databases

Research direction

Start from issue #1667 for the original reproduction and evidence, then read the project command implementations referenced by #1678 (the pending-directory repair) to see where canonicalization already exists versus where stored names are left untouched. Examine the merge and consolidate paths to understand why a lone spelling is rejected when normalized identities are equal. Done means a sanctioned CLI interface can normalize a single non-canonical project name without cloud sync or SQL, with tests covering that path; note the issue requires design sign-off before implementation.

Written by the indexing model from the issue text.

Description

status:needs-review type:feature
🔍 Problem Description

A legacy project with only one non-canonical spelling has no supported path to canonicalize its stored name without configured cloud sync or manual SQLite edits. Case-only merge can reject the source because its normalized identity already equals the destination; consolidation has no multi-spelling group to join.

This is the project-normalization requirement split from #1667. PR #1678 only repairs pending session journal directories and intentionally leaves local project/session names unchanged.

💡 Proposed Solution

Preserve the original requirement from #1667:

  • There should be a sanctioned way to normalize a single project that has only one spelling — e.g. a projects rename, or merge accepting normalizedSource == canonical when the raw strings actually differ — so the underlying name can be canonicalized without configured cloud sync and without hand-editing SQLite.

Choose the supported interface during design; this issue does not prescribe a new command or change merge/consolidate contracts.

📦 Affected Area

CLI (commands, flags)

🔄 Alternatives Considered
  • Pending-directory repair in #1678 canonicalizes repaired journal rows, not the underlying project/session names.
  • Consolidating a lone spelling has no group to join.
  • Case-only explicit merge can reject an already-equal normalized identity.
  • Manual SQL edits and cloud enrollment are not acceptable prerequisites.
📎 Additional Context

Split from #1667 with explicit scope approval; the original reproduction and historical evidence remain there. Original report: Engram 3.1.0 on Windows. Related #136 and #911 address other normalization cases; closed #1278 is a broader CLI-maintenance proposal.

Acceptance: a single legacy non-canonical project spelling can be normalized using a sanctioned interface, without cloud enrollment or manual SQLite edits. Implementation and data-migration safety require separate design and approval. No implementation is included in #1678.

Dominant language
Go
Stars
7.1k
Forks
729
Avg merge
9h 11m
Merged PRs (30d)
359

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Gentleman-Programming/engram

All issues in Gentleman-Programming/engram

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.