[immakermatty]

Plan: DEV-6664 (task task-2026-10-14-727), HumanAndMachine-ai Mission Control.

Status: ready for review

Why

On 2026-10-14 a person's assigned Remote Environment had no user.name / user.email. Publishing data from a repository-db app (git commit inside its data checkout) failed after staging with "Author identity unknown". Laptops work because their owners configured an identity long ago.

Until now the Platform deliberately wrote no Git configuration (F9's addendum of 2026-10-14, #377 / #412): Lazurio's own commits got the person's GitHub identity per commit (git -c), and every other commit in the Environment had nothing. Matěj decided: "Git Identity by měl řešit Launchpad při nastavování GH … v rámci onboardingu, kdy lidem nastavujeme nástroj GH, aby mohli fungovat ve svém environmentu, by se měla nastavit i ta identita."

Target state

After a person signs in gh through Lazurio, every commit in their Environment has an author, with no per-app workaround.

What changes

• The curated gh session (src/tools/login.ts, new src/tools/git-identity.ts). After the SSH key step, whatever its outcome, and before the session ends signed in, Lazurio checks each of user.name and user.email. A field that neither git's global nor system configuration names (includes followed) is written with git config --global -- <key> <value>. The value is the person's GitHub identity from gh api user, exactly as githubCommitIdentity builds it: the profile's name, else the login, and <id>+<login>@users.noreply.github.com. This is the one path behind Settings → Nástroje, the Environment's first run (which leads there), lazurio tools login gh and --ssh-key.
• Never overwrite. A field git already has is left alone. When both are present, GitHub is not even asked, so a workstation's identity stays as it is. Because gh api user runs between the first check and the writes, each field is checked again (global, then system) right before its own write. A field set meanwhile is skipped; a check that cannot answer writes nothing more (fail closed).
• Never on a Team Environment. The gh sign-in is already refused there (F19's addendum of 2026-09-28), so this step never runs. The session also asks the Team rule again right before each field's write and ends blocked before the next one. A field written before the Environment became a Team one stays, like an SSH key linked before.
• Clear status, not fatal. The signed-in state carries gitIdentity:
  • present;
  • set: fields names exactly what was written (never empty). If a later field was not written, incomplete: { reason: write-failed | config-unreadable, missing } says so;
  • not-set (this step wrote nothing) with git-missing, config-unreadable, viewer-unavailable (GitHub silent, or it returned another account than the one gh confirmed) or write-failed.
  • Recovery in every case: sign in again (it adds only what is still missing), or git config --global by hand.
  • The CLI prints what was set and, for the rest, the reason and the fix.
  • The Launchpad says aloud (cs/en) when publishing from the Environment would fail (a partial write included), and shows the set identity in the folded details.
  • The exit code still follows the SSH key alone.
• Agent fallback text. The gh catalog target state (activation.installation, also the "Set up with an agent" prompt) now includes the same identity rule and its proof.
• Docs. New F19 addendum of 2026-10-14 in docs/decisions.md (decision, alternatives, tests, risks). F9's addendum point 4 is marked as refined. content-sync.md, environment-tools.md and the commit-identity.ts / module-create-run.ts comments match.

What deliberately does not change

• identitySettings (the per-commit git -c fallback for Lazurio's own commits: Personalspace bootstrap, gbrain, module create) stays. It still covers Environments whose gh was signed in by hand or before this change, and those where the write failed. It never overrides git and writes nothing, so keeping it costs nothing. Removing it would bring back git-identity-missing on exactly those Environments.
• Existing Environments are not touched. They are fixed separately with the same rule; this PR covers new sign-ins.
• No Machines/provisioning change, no Doctor check, no rollout.

Verification

• bun run check (lint, typecheck, check:public, build:proof, smoke:proof, full bun test) after the review fixes: 3542 pass, 0 fail (3550 tests across 252 files), exit 0. After the rebase onto 64978cb (integrations only): check:static exit 0 and the affected suites 151 pass, 0 fail; CI runs the full suite on the head.
• New tests/tools-git-identity.test.ts runs the real login sessions (the consumer of the Launchpad server and the CLI). gh and ssh are fakes; git is the system's own, confined to a temporary home with its own system config. Cases covered:
  • missing → both fields set from gh api user;
  • no profile name → login as GitHub spells it;
  • present → file byte-identical and GitHub not asked;
  • only the name present → only the email added;
  • system config or an [include]d file counts as present;
  • GitHub silent or another account → nothing written;
  • a refused write → write-failed, still signed in;
  • Team rule turning true right before the write → blocked, nothing written;
  • Team Environment → git never run;
  • review regressions: the Team rule turning true between user.name and user.email; a value filled while GitHub answers (kept, reported as git's own); a malformed configuration appearing meanwhile (fail closed); the second write refused after the first (set + incomplete, completed by the next sign-in).
• tests/tools-curated-cli.test.ts: the CLI lines (not set, set, then silent once present). tests/tools-view.test.ts: strict parsing and the people-facing sentence.

Risks and open points

• Not run on Windows here. The curated session runs there too, and git config --global with HOME set to the operator's home is the same on Git for Windows, but this is untested on that platform.
• A person who wants a different address than GitHub's noreply one changes it themselves, as on a workstation.
• The noreply address only links commits to the account on GitHub. It does not reveal the person's private email.

🤖 Generated with Claude Code

[immakermatty]

CI note: tests (1/2) failed on the first run in tests/launchpad-prompts.test.ts ("hosted personal: new-personal-module …", expect(own.calls).toEqual([])). That is the known race #413: the Launchpad's start peeks the Personalspace holder in the background. It does not touch the gh sign-in path. It passes locally (full bun run check on this head: 3538 pass, 0 fail) and alone 3/3. The failed job was re-run.

[agentrozjedemeai]

Changes requested on 030bafe. The focused local suite passes (38/38), and CI is green, but two promised safety invariants are not enforced:

1. src/tools/git-identity.ts:136-157: proceed() checks the Team rule only once before the loop. If the Environment changes to Team after writing user.name but before writing user.email, the second write still runs; the final mayProceed blocks only after both writes. Please re-check the Team rule before EACH write and test the transition between the two fields. A deterministic runner probe produced state: set, two writes, and only one Team check despite the rule becoming true after the first write.
2. src/tools/git-identity.ts:113-156: the presence check and later git config --global write are separated by the GitHub API call. If the operator or another process fills a missing value during that interval, this step overwrites it. The same deterministic probe filled user.email with chosen@example.com in that interval; the returned state was set and the chosen value was replaced. This violates the explicit never-overwrite contract. Revalidate immediately before each write and make the read/write coordination fail closed where possible; cover the interleaving in a regression test.

Documentation also says no fields are written in any not-set case (docs/decisions.md F19 addendum point 5; docs/environment-tools.md), but a failure on the second write leaves the first field written and reports not-set/write-failed. The probe reproduced this. Either ensure an all-or-nothing outcome or document the actual partial-write behavior and recovery accurately.

The existing tests cover Team transition before the first write and existing configuration before the initial read; they do not exercise these interleavings. Windows and device sign-in remain unverified as disclosed.

[agentrozjedemeai]

Approved on exact head 7643d9b. The three prior blockers are addressed: Team eligibility is rechecked before each field write; a fresh global/system lookup avoids replacing a field populated during the GitHub call and stops on unreadable config; a second-field failure reports the first write as set+incomplete, with CLI/UI and documentation reflecting recovery. I inspected the caller and consumers, ran 42 focused tests (0 failures) and check:static locally, and confirmed the exact-head CI rollup is green with no open review threads. Windows and real device sign-in are not locally qualified here.