Repository navigation
graphify updates - #462
Merged
Merged
graphify updates#462
Conversation
![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: b65d778b98
ℹ️ 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".
| *.trx | ||
|
|
||
| .agents/skills | ||
| .claude/skills |
There was a problem hiding this comment.
When graphify update . runs, this broad ignore also matches the repository-owned, tracked .claude/skills/verify/SKILL.md; the regenerated graphify-out/manifest.json has already dropped that file while graph.json retains semantic nodes sourced from it, so future edits to the verification workflow will leave stale graph guidance. Narrow this rule to locally installed skills or explicitly unignore the tracked verify skill.
AGENTS.md reference: AGENTS.md:L185-L189
Useful? React with 👍 / 👎.
mforce
added a commit
that referenced
this pull request
Aug 31, 2026
…shboard ports (#623) * docs(aspire): record the second local database and pin the AppHost dashboard ports Aspire starts its own PostgreSQL on its own volume with a generated password held in the AppHost's user-secrets, so it is a second database rather than a view onto the Compose dev stack. Any run-then-exit verb started by hand is outside the AppHost's process graph and silently addresses Compose instead, which is how bootstrap-admin failed twice with two unrelated-looking messages before anyone suspected the database. Records that as decision 565 and threads it through the places someone would actually be standing when they hit it: AGENTS.md, CONTRIBUTING.md, the verify skill's pre-flight, deploy/README.md, the break-glass runbook, and a fourth form in the first-admin runbook for the Aspire stack. Also pins the AppHost's own endpoints, which are not resources and so cannot be reached by LocalPorts: dashboard 18888, OTLP 18889, resource service 18890. All three are plaintext loopback, so the profile sets ASPIRE_ALLOW_UNSECURED_TRANSPORT and the guard asserts that flag beside the http scheme it exists for; moving the URLs to https is what retires it. Only the host and port are stable, the dashboard's login token is still minted per run. Keeping the committed LocalPorts clear of 5432 and 6379 is load-bearing rather than cosmetic: ConnectionStrings:Default is a single value naming localhost:5432, so letting both stacks hold that port makes it mean "whichever stack is up" for every hand-run verb and IDE debug session. Disjoint ports keep the mistake loud. The .gitignore carve-out states an intent that was previously an accident. verify/ has been tracked since #43 while .claude/skills arrived in #462, and gitignore does not apply to tracked files, so the skill showed up in every diff looking unintentional. Verified: dotnet build clean, AppHost.Tests 10/10, Domain 361, Application 175. The launch-profile guard was mutation-checked - dropping applicationUrl, drifting the OTLP port, and switching the dashboard to https while leaving the unsecured-transport flag set each turn it red, and it passes again on restore. Integration tests and the SPA suite were not run; this diff touches neither. * docs(aspire): name the silent wrong-database success and fix AppHost detection CodeRabbit review on #623. All five findings were confirmed against the files before anything changed; the first is a factual error rather than an omission. The form 3 troubleshooting claimed running it against a live Aspire stack "surfaces as a connection error, never as anything about the database being empty". That holds only when Compose is down. With both stacks up - the normal state on a machine that uses either - form 3 reaches Compose and exits 0. Two shapes, both silent: Compose had no Owner, so it provisions one there and hands you a password for the wrong database; or Compose already had one and it prints "Admin already provisioned ... nothing to do", which reads as success while the Aspire database still has no Owner. Verified against BootstrapAdminCliCommand, which returns 0 on both paths. The failure table said the other stack holding the port produces a connection failure - holding the port is exactly what makes it connect instead. The verify skill detected a running AppHost with docker ps piped through grep -E 'postgres-|redis-', which also matches deploy-redis-1 and cluckwork-sim-redis-1, so Compose and the sim stack both read as Aspire. It also treated the LocalPorts defaults as fixed, though they are overridable and can be empty for a random port. Now detects the AppHost process, its pinned dashboard port, and aspire describe for the endpoints a given run actually holds. The same file told Aspire users to read Seed:* from the API's user-secrets, which are the Compose credentials. Split by stack, and separated the two passwords people conflate: Parameters:postgres-password in the AppHost's user-secrets is the database credential form 4 passes, never a login. The sign-in password is bootstrap-admin's stdout on the run that created the Owner, unrecoverable afterwards, so recover-admin rather than a hunt. Also a language identifier on one fence for MD040, and the drill's reset command had a literal ellipsis where the second docker compose invocation belongs, so copying it never restarted the stack. Swept for the same three defects across the touched docs: no other bare fence, no other placeholder inside a shell command, no other false absolute about how the mixup surfaces. AppHost.Tests still 10/10; no executable code in this commit.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
graphify updates