# A team frozen in time: what changed in v1.1.0, sgit.ai > The changes to the article "A team frozen in time" in v1.1.0, paragraph by paragraph. *Source: · sgit.ai v0.7.87 · this file is generated from the same content as the page, so the two cannot drift. Every page on this site has a `.md` twin; internal links below point at them.* --- [Home](../../../index.md) / [Articles](../../index.md) / [A team frozen in time](../../a-team-frozen-in-time.md) / [Versions](../a-team-frozen-in-time.md) / v1.1.0 # A team frozen in time: what changed in v1.1.0 From v1.0.0 (2026-10-24, `ab7e5dc61`) to v1.1.0 (2026-10-24, this release), paragraph by paragraph. 14 paragraphs added, 4 removed, 3 changed in place, 33 unchanged. About 692 words added and 62 removed. Insertions are marked like this, deletions like this; unchanged runs are folded to one line; figures appear as their file names. [all versions](../a-team-frozen-in-time.md) 1 unchanged paragraph Summary: Every project has a moment when the team is sharp, everyone is there, and features ship fast. Then the project dries out, the goals are met, or the company is sold, and the team moves on, taking with it the knowledge of why the system was built the way it was, its side effects, and how to build and ship it. Years later a fix is needed, as with PHP this week, and nobody can make it safely; sometimes even the pipeline is gone. I am now experiencing something we never had: agent sessions that are focused on one piece of work, with one mandate, one role and one repository, which can be paused and picked up again later, with the conversation, the reasoning, the lessons and the code exactly where they were. The best examples are the teams behind the sgit CLI and SG/Send, the vaults, which I keep coming back to: one of their sessions has resumed after 43 days without a commit, and another after 36, starting from the current code and getting straight back to tested work. On the PHP story's team, two sessions did exactlythethatsame this week:weekeach left off on 22 October and carried onafter 28 hours later, by first reading what the rest of the team had done.hours. A new developer who joins such a project inherits the history, the materials, and agents ready to make the change. That is a very powerful idea, and I want to capture it. 6 unchanged paragraphs, under In short {#in-short} • **We have seen it this week.** Two PHP-team sessions resumed after 28 hours by first reading what had changed. • **The sgit teams show it best.** Sessions on the CLI and SG/Send resumed after 36 and 43 days, from the current code. • **And this week, too.** Two PHP-team sessions resumed after 28 hours by first reading what had changed. 7 unchanged paragraphs, under The team that leaves {#the-team-that-leaves}, A session with one mandate {#one-mandate} ## We saw it this week {#this-week} The PHP story's git history shows it plainly, because every commit names the session that made it. ## The teams I keep coming back to {#sgit-teams} The best examples are the teams behind [the sgit CLI](https://cli.sgit.ai/), whose source is [SGit-AI/SGit-AI__CLI](https://github.com/SGit-AI/SGit-AI__CLI), and behind SG/Send, the vaults, in [SGraph-AI__App__Send](https://github.com/the-cyber-boardroom/SGraph-AI__App__Send). I have dedicated Claude Code sessions for that work, and every commit they make names its session, so their git histories show when a session went quiet and when it came back. Increasingly there are long periods when they are paused. And when they start again, they pick up where I left them, with a lot of quality. [figure fz-pauses.webp] Four sessions that keep coming back, from the git histories of the sgit CLI and SG/Send: an SG/Send session over 158 days with pauses of 23.5, 18.9 and 43 days; another over 69 days with a pause of 37; a CLI session over 86 days with pauses of 15, 15 and 36; and another over 47 days with pauses of 22 and 17.5. Each pause was ended by the same session. | timeline • **SG/Send, a 43-day pause.** One session's last commit before the pause, on 29 June, updated a dependency with the full unit suite at "977 passed, 9 skipped". Its next, on 11 August, started from the current dev branch, 19 releases later, with "Add DevOps review: API deployment current state, container unification, and AWS Marketplace". The next day it shipped "Phase A: universal container image", with "Container unit tests: 36 green", and the deployment templates with "all cfn-lint clean". The same session had paused for 23.5 days in the spring and come back with "rebase debrief to v0.27.53 after dev sync": catch up first, then work. • **SG/Send, a 37-day pause.** Another session stopped on 9 June with a fix to the vault editor and came back on 16 July with documentation, then a review of its own docs against the live sources, the fixes from that review, and then features: "native LLM chat, talk to the file you are viewing". • **The sgit CLI, pauses of 15 and 36 days.** One session came back on 30 June after 15 days with a dependency fix: "sgit-ai full unit suite on Python 3.11 with osbot-utils 3.75.0: 3822 passed, no regressions". After 36 more days it came back with a security review and threat model, "analysis only; no code changes". • **Both teams at once.** On 8 April a CLI session, quiet for 9 days, shipped a fix rejecting human-readable vault IDs; 16 minutes later an SG/Send session, quiet for the same 9 days, added the server-side check: "complements the client-side fix already shipped in sgit", with 8 new tests. Two honest qualifications. These are not one session per project: the CLI's history has 19 sessions and SG/Send's 240, many of them short, so the repositories never stopped; it is the long-lived sessions that pause. And a gap in commits does not prove a session was idle, only that it committed nothing. The commit trailers also suggest that some of these sessions carried on across a change of model, which is the point: the session kept its context while the model behind it moved on. ## And this week {#this-week} The PHP story's git history shows the same thing on a short scale, because every commit names the session that made it. 3 unchanged paragraphs The gap here was about 28 hours,hours.notWithmonths.theButsgitnothingteams it has been more than a month. Nothing in how this works depends on the length of the gap.gap:Thethe session, the repository and the record are the same whether it waits a day or a quarter. 12 unchanged paragraphs, under Why this is so powerful {#why-powerful}, What it takes {#what-it-takes}, What this does not claim {#limits} • **The gap observed was 28 hours.** Months is the promise of the design, not yet a measurement. • **The longest pause observed is 43 days.** Years is the promise of the design, not yet a measurement. • **Commits are the evidence.** A session that commits nothing may still have been open; and the CLI and SG/Send also have many short sessions alongside the long ones. 4 unchanged paragraphs, under Where this comes from {#sources} My voice memomemos of 24 October 2026; the git histories of [SGit-AI__CLI](https://github.com/SGit-AI/SGit-AI__CLI) and [SGraph-AI__App__Send](https://github.com/the-cyber-boardroom/SGraph-AI__App__Send), all branches, keyed on the session named in each commit, read on 24 October; the PHP story site's git history, its commits grouped by the Claude Code session named in each, 22 to 24 October; its [team status page](https://php.oct.2026.newsroom.sgit.ai/team/status/). Related: [the agents write too](https://newsroom.sgit.ai/articles/the-agents-write-too.html), [almost working](https://newsroom.sgit.ai/articles/almost-working.html), [who will fix your mess?](https://newsroom.sgit.ai/articles/who-will-fix-your-mess.html), [who maintains the PHP you run?](https://newsroom.sgit.ai/articles/who-maintains-the-php-you-run.html), [PHP October 2026, update 2](https://newsroom.sgit.ai/articles/php-daily-2026-10-23.html). Written up and checked by this site's agent, newsroom.writer; the editorial responsibility is mine. [all versions](../a-team-frozen-in-time.md) --- *[Site index for agents](../../../llms.txt) · [HTML version](https://newsroom.sgit.ai/articles/versions/a-team-frozen-in-time/v1.1.0.html)*