liliu-z/stashbase

Problem StashBase already shows ordinary user dotfiles such as .env and .gitignore, but it drops every dot-prefixed directory before building the Files tree. As a result, user-owned project content under directories such as .github, .vscode, .claude, and .obsidian cannot be inspected from the workspace or reached through Quick Open. The current blanket rule keeps scans bounded and protects derived/tool state, but it treats all dot-directories as infrastructure. Users who deliberately need hidden project files must leave StashBase, and the Files surface offers no way to opt into a more complete view. Product decision Add a checkable Show hidden files action to the Files panel menu. Keep the current safe view as the default: ordinary user dotfiles remain visible, while dot-directories remain hidden until the user opts in. Persist the preference as an application-level workspace setting and apply it consistently to every open window. A missing or invalid value recovers to false. When ena

What to build Add a minimal Import from GitHub… flow to the Library switcher. A user pastes a public GitHub repository URL, confirms the generated local folder name, and StashBase clones the repository into the fixed StashBase folder home. On success, the result joins the Library and opens through the existing folder workflow. GitHub is only an acquisition source. The imported working tree is an ordinary local folder and remains the source of truth for browsing, editing, preparation, indexing, search, and Agent access. Preserve its .git directory as hidden infrastructure so external Git tools can continue to manage it. Removing the folder from Library must not delete the local repository. User experience Add this pinned action above Library membership: Import from GitHub… Clone a public repository into your StashBase folder home The modal contains only: Repository URL: a complete https://github.com/<owner>/<repo> URL. Folder name: derived from the repository name and editable as

Summary After a user signs in to StashBase with Google, show their actual Google profile identity — display name and avatar — across the signed-in account UI. Keep the email address available as the stable human-readable account identifier, but do not use it as the primary identity label when profile data is available. This should make the account surface read as “this person is signed in,” rather than merely “this email address authorized hosted AI Index usage.” Context The current OAuth flow intentionally keeps the refreshable Supabase session in the Node service, but its normalized session model retains only the user ID and email. The renderer account state therefore has no display name or avatar to show. The current UI compensates by: using the full email as the sidebar account label; generating a monogram from the first two email characters; presenting the portion before @ as though it were a name in the account menu. An email local-part is not a reliable display nam

Summary Add .xlsx as a first-class read-only convertible source. Users should be able to open a workbook in StashBase, navigate its worksheets, copy visible cells, search its contents, and let Agents read a source-attributed textual representation. StashBase must not edit or save workbook content. The original OOXML package remains the source of truth and can still be changed by an external spreadsheet application. This is intentionally separate from #127, which only made unsupported files understandable. It is also separate from the editable CSV work in #164: XLSX is a compound packaged document with formulas, styles, relationships, drawings, and application-specific fidelity requirements. Problem XLSX files are currently hidden as unsupported files. A user cannot inspect a workbook next to related notes and documents, find a cell through StashBase search, or give an Agent useful workbook context. Treating XLSX like CSV would create a misleading editor. Rewriting an OOXML package safe

Summary Add .csv as a first-class direct-text structured-data format. A CSV file should be visible, searchable, readable as a table, editable in a grid, and editable as raw source without being converted into a note or a hidden derived file. This is intentionally separate from #127, which only made unsupported files understandable, and #149, which added JSON as a first-class structured-text source. Problem CSV files are common interchange artifacts, but StashBase currently treats them as unsupported. That means a user cannot inspect a dataset in context, correct a cell, search it, or give an Agent useful access to it without leaving the workspace. A naive implementation that parses the file and serializes the whole table on every save is not acceptable. It can silently change delimiters, quoting, line endings, leading zeros, empty rows, multiline fields, and other untouched source text. Product decision CSV belongs to the same product class as JSON: the original file is readable source