Skip to content

Conversation

@aaronjeline
Copy link
Contributor

Fixed three issues I ran into while onboarding

  1. The build-app script assumes you have access to Niko's singing material
  2. The "open project" button returns you to the main screen if you try to open a directory not initialized as a Symposium project. It now displays an error message before doing this. (I had initially assumed I added symposium to an existing project)
  3. The bare git clone did not set up the git references for the remote, causing taskspace creation to fail.

Let me know if you want any stylistic changes.

When picking a non-symposium project, the user
will now get a nice error message.
Also fixed build script for people who are not
Niko.
Bare repo clones don't set up all the references that full clones do.
Since we want the root repo to be a bare clone, we have to do some of
that setup manually.
@nikomatsakis
Copy link
Member

(I had initially assumed I added symposium to an existing project)

You know...it might be nice if this worked....

Copy link
Member

@nikomatsakis nikomatsakis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The code change themselves look good. I am unclear on how .kiro steering files are supposed to work -- in general I've been trying to use md as the place to store collected documents that will guide LLMs. I'd rather not "hardcode" to Kiro, kind of goes against Symposium's unopinionated design philosophy.

@@ -0,0 +1,242 @@
# Design Document
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So--- it's a bit unclear to me how these docs are intended to fit into the workflow. Is it intentional that you commit these? And how does it fit with a project where some people are using Kiro and some are not? This document in particular seems like it is specific to this PR and could quickly become outdated.

The more "Symposium-way" would be to edit and extend the mdbook's design section.

@@ -0,0 +1,88 @@
# Technology Stack

## Build System & Workspace
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems useful enough but it feels like it should probably just be in an AGENTS.md if we don't have one already,I forget.



/// Execute a process and return results
private func executeProcess(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is good 👍

let process = Process()
process.executableURL = URL(fileURLWithPath: "/usr/bin/git")
process.arguments = ["rev-list", "--count", "\(branchName)", "--not", baseBranch]
let remoteBranch = "origin/\(baseBranch)"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not thrilled about hardcoding origin here (and elsewhere) -- let's at least pull it into a constant somewhere.


Logger.shared.log("ProjectManager[\(instanceId)]: No default branch configured, auto-detecting from git")

// Auto-detect origin's default branch
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Side note: we really need to have tests for this kind of logic

@aaronjeline
Copy link
Contributor Author

The code change themselves look good. I am unclear on how .kiro steering files are supposed to work -- in general I've been trying to use md as the place to store collected documents that will guide LLMs. I'd rather not "hardcode" to Kiro, kind of goes against Symposium's unopinionated design philosophy.

Ack, shouldn't have committed these, mistake on my part, meant to put them in a gitignore

- Add remoteName property to Project struct with 'origin' as default
- Update ProjectManager to use project.remoteName instead of hardcoded 'origin'
- Support for projects using different remote names (upstream, source, etc.)
- Maintain backward compatibility with existing projects

Co-authored-by: Claude <[email protected]>
Copy link
Member

@nikomatsakis nikomatsakis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This LGTM! At the moment, from what I can see, there is no GUI to edit the remote name, right? But you could edit the JSON by hand I guess.

@nikomatsakis nikomatsakis merged commit 269adcc into symposium-dev:main Sep 28, 2025
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants