AngeloProfileBriefDashboardMeet page

Angelo's dashboard

Open Angelo's command centre: tasks, workstreams, decisions, agents and Ask Claude, built from the repository at every release.

Everyone's command centre: Dinis · Silvio · Nimay · Angelo · Vicky · Daniela · Indi · Jose · Sarah

Before the next stand-up

Your briefing for 2026-11-03 13:00 UTC · the agenda

Since you last looked

ReleasesAgent and people commits
Today (since 00:00 UTC)4058
The last 24 hours100132
Since you last acknowledged (never: showing the last 24 hours)100132

Newest releases since then:

Seen it? Tell your agent "acknowledge": it writes people/angelo/ack.json with the time, and your next briefing starts from there.

My agents, as the team sees them

From your mentor

Your core agents, ready to start (three steps each): your kit.

2026-11-02-2250: From mentor@web-summit.angelo, to Angelo and his agents. Suggestions only: take what helps.

L3, 7 of 9 steps on the setup leaderboard, with three agents. The next step is the dashboard agent (how); its prompt is already in your kit (linked above). After that come the vaults.

Your conductor joined (2fb57df). Dev joined and published its key (fc79f3e, 746a42b, ebbe647). Team-collaboration joined and put the stand-ups on the calendar (06cee32, 996cee0, 97ccdaa).

  1. Start the dashboard agent. It gives your conductor a solid page to brief you from, and a stable place where what needs you is always found. One session, one paste, then a scheduled task.
  2. Make the agents you have visible. Dev's key is on the keys page; the conductor's and team-collaboration's public keys are not yet in data/keys.json. Each agent can add its own entry, which makes the setup verifiable rather than declared.

Team-collaboration's calendar work raises one question already on the 3 November 13:00 stand-up agenda (WS-96): did it send the invitations itself, and should its calendar connection be draft-only? No new item needed; your answer there settles it.

Everything above is built for you; everything below is yours and your agents' to change (people/angelo/dashboard.md).

This page is Angelo's, kept by Angelo and Angelo's agents in people/angelo/dashboard.md. It starts the same as everyone's: change it to show what you want to see when you wake up, take ideas from the others, and the best of them go on the main page.

Today

My issues

IssueWhat, and what done looks likeForDueStatus
WS-01Get to L1: a dedicated Claude account for this work. A Claude account (or a dedicated project in yours) used only for Web Summit, with a first session that has read the start page and your brief. Tick claude in your onboarding file.everyoneTue 3 Novopen
WS-02Get to L2: GitHub, push access to this repository, and an email you can send from. Your GitHub username sent to Dinis and accepted as a collaborator; your agent has cloned the repository and pushed its first commit (your onboarding file, people/<you>/onboarding.json) with the commit convention; an email address you can send from (your own, or a workspace account Dinis creates).everyoneTue 3 Novopen
WS-03Get to L4: your agents' keys published, and a dashboard agent. Corrected 2 November (evening): no browser registration. Each agent makes its own key in its session (pki-agent.mjs keygen --session) and commits the public half to the keys page (data/keys.json); the push is the authorisation. With your dashboard agent running, that is L4. Steps 5 and 6 on the start page.everyoneWed 4 Novopen
WS-04Get to L4: a Claude session on a schedule. One scheduled session (for example every morning at 08:00 Lisbon) that pulls the repository, reads the board and your dashboard, asks you for your pulse, and tells you what is waiting on you.everyoneWed 4 Novopen
WS-05Get to L5 and L6: several agents, then several scheduled sessions. Your agents named by the convention (<agent>@web-summit.<you>), run as sub-agents in one session (L5); then a separate scheduled session for each agent that runs on its own schedule, and a separate session per topic (L6).everyoneThu 5 Novopen
WS-06Make your dashboard yours. people/<you>/dashboard.md changed to show what you want to see when you wake up: your issues, your meetings, your agents' last runs, anything you take from someone else's. Others will copy the best ideas into the main page.everyoneWed 4 Novopen
WS-07Pulse check-in, three times a day. Morning, midday and evening: your agent interviews you for two minutes (or you type) and commits people/<you>/pulse/<date>-<slot>.md: your understanding of the situation, blockers, what we should be doing that we aren't, what works, what doesn't, ideas, and how you feel. Public, on the pulse page.everyonedaily from Tue 3 Novopen
WS-08Fill in your card. Answers to the questions at the end of your brief, committed to people/<you>/card.md or sent to Dinis.everyoneTue 3 Novopen
WS-100The GitHub account step, documented for newcomers. Step 3 on the start page, with screenshots or a short video: create the account with your Workspace email, send Dinis the username, accept the invitation, and how your agent pushes with it. Written from what went wrong today.Angelo, VickyTue 3 Novopen
WS-102Seal the vault keys to keys on the keys page: the push is the authorisation. Decided by Dinis (2 November, evening): a key is trusted because it was pushed to this repository, not because it is in the pki.sgit.ai register. Only an account with push access to SGit-AI/SGit-AI__Website__Web-Summit can put a key on the keys page, so the push is the authorisation (the push is the authorisation, CLAUDE.md "Identity and names"). This issue's first version said the opposite (that pki-agent.mjs seal needs the register, so a choice was needed). That was wrong for this team: the register is a check that pki-agent.mjs seal makes, and not our trust rule. Done: admin/tools/seal.mjs seals a secret to a key on the keys page. It reads the recipient's bundle from origin/dev:data/keys.json (what was pushed, not a local edit), names the commit that pushed it, and refuses if the copy the live site serves (/keys/sha256-<fp>.json) differs. The sealing is pki-agent.mjs's own code, unmodified. It is loaded from the downloaded tool and its sha256 is printed. The output is a pki.sgit.ai sealed link (and a QR code, with --qr) that the recipient opens with node pki-agent.mjs open. A test secret was sealed to sgit-dinis and opened by that session from both the link and the QR code, on 2 November. Steps: the vaults page. Next, not this issue: sealing the six team vault keys to the team's agents (step 8) needs the holder of those keys, the vault registry key, to run this tool. Open questions from the article stay open here too: proof that the session holds the private half, which writer may replace which role's key, and retiring an old session's key. Agents: sgit@web-summit.dinis built and tested the tool.Dinis Cruz, Angelo, Jose BotaWed 4 Novdone: sgit@web-summit.dinis
WS-105Protect main: pull requests only, merged by Dinis. On 2 November at 23:06 the conductor pushed to main directly when asked for a major release. A rule did not stop it; a setting would. In the repository's Settings, Branches (or Rules), add a rule for main: require a pull request before merging, and restrict who can push to Dinis (and Angelo if wanted). Also, in Settings, Environments, github-pages, add main to the deployment branches, or the major release cannot deploy (the 23:06 run's release job was refused before it started). Done looks like: an agent's push to main is refused by GitHub, and a merged pull request from dev releases v0.2.0. 2 November, 23:48: the github-pages environment now allows main (v0.2.0 deployed from the merge of PR #1). Branch protection on main: to confirm (an agent push to main should be refused).Dinis Cruz, AngeloTue 3 Novpicked
WS-106Meet the estate's repository standard: the gaps. Read against https://sgit.ai/docs/guidance/repositories.md and /docs/guidance/index.md on 2 November, at Dinis's word. Done on 2 November (v0.2.2): the version in the top bar of every page, linked to its own row, each release recording the commit it was built from and its tag; the gate checks em-dashes in prose (17) and that every script parses (18). Still missing, one per pass, each into REALITY.md when done: 1. review/, with review/self/: the project as layered graphs, intent from the brief, code from the tree, every commit read upwards (the review brief on sgit.ai). 2. The Agent Contact file at /.well-known/sgit-agents.json (sgit.ai, Agents). 3. A row on nfrs.sgit.ai: the honest column, what this site meets and what it does not. 4. Tests against real things, beyond the gate: the build, the release step (as the 2 November simulation did), the onboarding levels, the meetings carry-over. 5. llms.txt per section, not only at the root. 6. Versions as data: versions/index.json and one file per version (version, date, commit), as /docs/guidance/index.md shows. 7. Each release says what it does not prove, in its versions row. 8. The leak tripwire against the staged diff in release.sh, including the secret parts of every key held locally (the session keys). 9. The roles file per role with the mistake behind each rule (team/<role>/ROLE.md). Progress (dev@web-summit.dinis, 3 November, 00:41 wake): item 6 done. The build writes versions/index.json (site, latest, every version with its date, commit, tag, author and sentence) and one versions/<version>.json per release, from admin/versions.json, which CI alone writes; linked from /admin/versions.html. Note for the conductor: two board files carry the id WS-106 (this one and security's "confirm who pushed the recipient's key"); one needs a new number. Agents: dev@web-summit.dinis takes one per refactoring pass; dev@web-summit.angelo welcome.Angelo, Jose BotaFri 6 Novopen
WS-107Stand-up decisions recorded in the person's own words, with where and when. From the newsroom articles (part four: decisions "are not yet being recorded as decided"; "A pen on a release candidate"). From the 13:00 stand-up of 3 November, every decision is closed with node admin/tools/agenda.mjs decide: the person's words verbatim, who said it, where (stand-up, chat, voice note) and when. Nobody records a decision for someone else in their own words. Done when: the 13:00 stand-up's decisions show Decided on /meetings/, and the briefings stop carrying them over. Agents: conductor@web-summit.dinis (records), project-manager@web-summit.dinis (reviews), every person's conductor.Dinis Cruz, everyoneTue 3 Nov, 13:00open
WS-109"The grant, not the prompt" as the one demo, and its lines for the shirts and the stand. From the newsroom article "The grant, not the prompt": ask an unrelated chat "what emails do I have?", and explain that the access was set at the click that granted it, not at the prompt. The proposed one demo for WS-15. Candidate lines, for Dinis to choose (nothing printed without his word): "Authorised at the click, not the prompt"; "How much of your agent policy is hope?"; Silvio's "Your AI has access. Does it have permission?" (already on /print/). Done when: a two-minute demo script under content/abp/ and the chosen lines in data/design.json. Never present SHarness or signed email as shipped. Agents: designer@web-summit.dinis (data/design.json, the stand), abp@web-summit.dinis (the demo script).Dinis Cruz, everyoneWed 4 Novopen
WS-112Every person's conductor briefs its person (people/<id>/briefs/, ack.json), with a review step. From the newsroom article "How an agent team briefs its people", which says every person gets a brief: none of people/*/briefs/ or people/*/ack.json exists yet. Each person's conductor writes its first brief (the shape and tool: /articles/how-we-brief-the-humans/), sends the PDF, and writes ack.json when the person has read it. Plus a review step before a brief goes out (a second agent checks every number against its source), and gate warnings for a brief with more than three asks, or next, sources or wide as a string instead of a list. Agents: every person's conductor; conductor@web-summit.dinis (the gate warnings).everyoneWed 4 Novopen
WS-113Print files ready for sign-off, and an Official Sign-off on /print/ that everyone signs with their agent's key. From Dinis, 3 November 2026, on Silvio's review of /print/: "yes get everything ready for the sign-off, can you make it so that we all have the ability to sign off (via our agents and github + our agents signature (via PKI)) ... ask it to implement a typical Official Sign-off UX". Written by procurement@web-summit.silvio. Why today: the printer that fits (seven colours, Friday delivery in Lisbon) needs the files, the sizes and our confirmation by the end of Tuesday 3 November (the print order). ## 1. Fix the files before anyone signs (designer@web-summit.dinis) From a printer's-eye check of the zip (2 November, v0.2.23), most important first: 1. The hoodie back is 260 x 510 mm: too tall. A hoodie back takes about 350 to 400 mm of height, and the hood covers the top: "AGENTS UNDER POLICY" would sit under the hood. About 300 x 380 mm, starting 120 mm or more below the collar seam. 2. The T-shirt front is 280 x 306 mm on every size, nearly A3: too wide for XS, S and women's fits, stiff, and DTF is priced by area. About 250 mm wide (or a second, 220 mm version for XS, S and women's). 3. Thin strokes. The light "RISK" of the wordmark is about 0.5 mm thick on the 13 mm hoodie chest logo, below what DTF holds well. On the chest: the bold weight only, or the logo at 100 to 120 mm wide. Nothing thinner than 1 mm anywhere at print size. 4. Colours a printer can buy. Each person's garment colour as the nearest stock colour of the printer's blank (the printer that fits uses B&C Exact 190 T-shirts), not only a hex value: name it in final.json and on the page. ## 2. The Official Sign-off (designer@web-summit.dinis, on /print/) The mechanism is ready (procurement@web-summit.silvio): admin/tools/signoff.mjs. A person's agent, on the person's own words: `` node admin/tools/signoff.mjs sign --person <id> --by <agent> --said "<their words>" [--decision changes --note "..."] node pki-agent.mjs sign people/<id>/signoff/print.json # the agent's key, on data/keys.json git commit (Agent: <agent>, Issue: WS-113) and admin/tools/release.sh node admin/tools/signoff.mjs verify [--json] # anyone: every signature checked ` The statement holds the sha256 of every file in the person's set, so a sign-off covers exactly those bytes: if a file changes afterwards, the sign-off shows as **superseded** and must be signed again. verify checks the signature against the key on data/keys.json and that the key is the agent's who signed. Statuses: approved, changes requested, superseded, unsigned, bad signature, awaiting. **The UX to build** (a typical official sign-off, as on a contract or a print proof), on /print/ for each person and for the shared designs: - A **status badge** at the top of each set: AWAITING SIGN-OFF (grey), APPROVED (green), CHANGES REQUESTED (amber), SUPERSEDED: RE-SIGN (amber), BAD SIGNATURE (red). From check() in admin/tools/signoff.mjs, at build time. - A **signature block** once signed: the person's name, their words in quotes, "signed by <agent> with key <fingerprint>" linking to the key on /keys/, the date and time (UTC), and the commit that recorded it. - The **proof shown as signed**: the files listed with their sha256 (short), and the version of the site they were signed at. - A **summary bar** at the top of the page: "4 of 7 signed off; hoodie and card: awaiting Dinis"; the zip's download button says **"Final, signed: send to the printer"** only when all seven and the shared designs are approved, and **"Draft: not for print"** until then. - **How to sign** in a box under each unsigned set: the three commands above, with that person's id filled in, and "tell your agent: sign off my print set" for people. - Dinis signs the **shared designs** (hoodie, card) the same way, as --person dinis --set entries or a shared set; and may sign for anyone on their word (the statement says so). - The gate (validate.js, the conductor's): a bad signature fails the build. ## 3. The order sheet (procurement@web-summit.silvio) Sizes, per person, written by their agent to people/<id>/merch.json: {"tee_size": "M", "tee_fit": "unisex/women", "hoodie_size": "L", "updated": "2026-11-03"}`. The order sheet (colour, stock colour name, sizes, quantities) goes to the printer with the signed files. Done when: the four fixes are in the files, /print/ shows the sign-off UX, all seven sets and the shared designs are approved and verified, and the order sheet has everyone's sizes. Agents: designer@web-summit.dinis (the files and the sign-off UX), procurement@web-summit.silvio (the sign-off tool, the order sheet, the printer), every person's agent (signs its person's set).Dinis Cruz, everyoneTue 3 Nov, 16:00open
WS-117Sign in with pki.sgit.ai, on a signing origin of its own. From Dinis, 3 November: people sign in their own browser with keys from pki.sgit.ai (the OAuth-like flow). The plan is on Sign in with pki.sgit.ai. pki.sgit.ai keeps the browser key in the site's localStorage, unencrypted. On web-summit.sgit.ai every person's agents can publish scripts (people/<id>/app/app.js), so any of them could read anyone's signing key. Decision for Dinis: a separate signing origin (e.g. sign.web-summit.sgit.ai) serving one page, pki.sgit.ai's pinned module with its hash, and a strict CSP. Then: pin root sha256:db7f79fdd87e030a, ask for sign:approval for 7 days, and the print sign-off (level 2 on the sign-off page) is the first use. Agents: dev@web-summit.dinis (the page), security@web-summit.dinis (review before first use).Dinis Cruz, Angelo, Jose BotaThu 5 Novopen
WS-120Vaults, first through: Angelo, Jose and Silvio start a vault agent, make a vault and publish it. From Dinis, 3 November: everyone now has an SG/Send access token and should be creating vaults and experimenting with them. Angelo, Jose and Silvio go first. Follow your vault agent: 1. The token goes in your Claude environment as SG_SEND_ACCESS_TOKEN (never in chat). 2. Start vault@web-summit.<you> with the prompt on that page. Its key goes on the keys page. 3. Make a first vault with a README, push it, have a security sub-agent audit it, and publish its read key in people/<you>/vaults.json. 4. Optional: a small vault app or _page.json page, from one of the published examples. Done looks like: each of the three has a vault listed on /vaults/ that opens read-only, and a commit that corrects whatever was wrong or missing on the vault-agent page. The page's commands come from sgit.ai's documentation and have not yet been run end to end in a team environment. Agents: vault@web-summit.angelo, vault@web-summit.jose, vault@web-summit.silvio (Silvio's sgit@web-summit.silvio can do it); sgit@web-summit.dinis helps.Angelo, Jose Bota, Silvio SwithaWed 4 Novopen
WS-121Everyone runs a vault agent and publishes a vault. After WS-120 (Angelo, Jose, Silvio), everyone: the access token in your Claude environment, a vault agent, and at least one public vault listed on /vaults/. Steps: your vault agent. Vault keys travel only as sealed QR codes. Confidential vaults (the CRM, meetings, contacts) are the exception and get no published read key. Agents: each person's conductor starts vault@web-summit.<person>; sgit@web-summit.dinis keeps the guide.everyoneFri 6 Novopen
WS-123The site for you: every section from each person's point of view, with pictures of what is going on. Dinis, 3 November: "allow the visitor to choose who they are (local storage for now, the vault later), and the whole website shows the information for them: what changed, the latest from their point of view, what they and their agents are working on. The dashboard agent manages these parts, and each major section has this structure." And: graphs and visual representations of what is going on (the schedule and the agents map are the model). Done (the foundation, conductor): a "Who are you?" picker in the top bar of every page (localStorage ws.me); /me.json built at every release (per person: level, next step, urgent issues, decisions waiting, agents, messages, a 10-day activity series, since-you-looked); assets/me.js renders a For you panel at the top of every page, different per section (home, start, team, work, summit); anything marked data-for="<ids>" is highlighted for the chosen person (the home page's Needs you cards). Next, by owner: 1. dashboard@web-summit.dinis owns the panels' content from now: what each section shows first for a person (assets/me.js, the blocks per section, and the fields in me.json in admin/build/build.mjs). Add data-for to the lists on each section (the board, the stand-ups, the map, the reports) so the chosen person's items light up, and an "only mine" switch. 2. designer@web-summit.dinis owns the look: one visual language for the For-you panel and the site's charts (the schedule, the agents map, activity, the onboarding rings), on a phone first; a spec in team/designer/for-you/ before the build. 3. dev@web-summit.dinis: the charts as small build-time SVG helpers anyone can call (a timeline of each day's runs from the agents' schedules, the agents map per person, a burn-down of the board), and the gate checks on me.json (no contact detail, the shape). 4. journalist@web-summit.dinis: a "for you" line per person in each report, from me.json. 5. security@web-summit.dinis: review that choosing a person is described as a view, never a sign-in, and that me.json holds only what the pages already show. 6. Every person's dashboard agent: say what your person wants first in their panel (a commit For: dashboard@web-summit.dinis). Not in scope until the vault: anything private. The vault version (WS-102) will put a person's private view behind their key. Progress on 3 (dev@web-summit.dinis, 3 November, 03:40 wake): the gate checks on me.json are in. Check 19: the version, one entry per person on the roster, each field's type, issue ids, the activity series' length, and every link and briefing resolving to a page. Check 15 (comms_check) now also scans the generated public JSON the pages read (me.json and each command centre's data.json) for emails, phone numbers and key shapes. Each was shown to fire on planted bad data. Next: the chart helpers, in the look the designer sets under 2. Agents: conductor@web-summit.dinis, dashboard@web-summit.dinis, designer@web-summit.dinis, dev@web-summit.dinis, journalist@web-summit.dinis, security@web-summit.dinis, every person's dashboard agent.Dinis Cruz, everyoneFri 6 Novpicked: conductor@web-summit.dinis (the foundation); dashboard@web-summit.dinis (the panels); designer@web-summit.dinis (the look)
WS-18The demos we run at the summit. Two or three demos that show RiskMandate in a company's own world, rehearsed, each runnable from a phone or a laptop in five minutes.Nimay Parekh, Dinis Cruz, Angelo, Jose BotaWed 4 Novopen
WS-19The card-to-analysis loop, tried on three companies. For three priority-1 companies: the company analysis, the risk analysis and how RiskMandate helps, each made by an agent in under an hour and reviewed by a person. This is what happens to every card at the summit.Nimay Parekh, Indi Gupte, anyoneWed 4 Novopen
WS-20The landing page we send people to. One page with the message, what we want them to do, a meeting link and how to try it.Nimay Parekh, Indi Gupte, AngeloThu 5 Novopen
WS-26The big outreach: 50 targets for Thursday and Friday. Fifty companies and people at the summit, sourced, each with an owner and a drafted message, ready to send on Thu 5 and Fri 6.Silvio Switha, Indi Gupte, anyoneThu 5 Novopen
WS-27The factory: a page or vault per target company. For each target: its analysis, its risk analysis, how RiskMandate helps, published so the message can link to it. A pipeline where anyone can pick up the next company. Agents: factory@web-summit.indi makes them; a person reviews each.Indi Gupte, anyonefrom Thu 5 Novopen
WS-30Owners for the 20 priority-1 companies. Each priority-1 company on the map has one owner among the seven.everyoneTue 3 Novopen
WS-32The sessions each person attends. 3 to 6 sessions each from the summit page, with the speakers worth meeting.everyoneSat 7 Novopen
WS-33Make the repository safe for everyone to commit to all the time. Everyone's agents push many times a day without colliding: the release script (admin/tools/release.sh, a first version) tried by two people at once, CI kept fast, and a decision on whether CI should build and bump instead.Angelo, Jose BotaTue 3 Novopen
WS-34Behaviour policies for every agent and every person. A behaviour policy for each agent on the team (what it may read, write and never do) and for each person, made by interviewing them with their agent; the gate checks them.Angelo, Jose BotaWed 4 Novopen
WS-35Help each person through setup (L1 to L4). Everyone at L4 by Wednesday evening; what went wrong written down for the next person.Angelo, Jose BotaTue 3 to Wed 4 Novopen
WS-36A conductor of conductors. How the agents in everyone's accounts coordinate: who opens what, how they talk (commit trailers), how a stuck agent is noticed.Angelo, Jose Bota, Dinis CruzThu 5 Novopen
WS-37Observability lanes on the site. Who visits, what they read, where they came from, shown as a page we can all read.Angelo, Jose BotaThu 5 Novopen
WS-38Encrypted materials on the site, readable only by named team members. A file published on the site that only the named people's PKI keys can open (for example the week's vault access keys), and the steps to do it again.Angelo, Jose BotaThu 5 Novopen
WS-40Hosting for Silvio's videos. Somewhere the videos live that the site can embed and that YouTube and Instagram can be fed from.Angelo, Jose Bota, Silvio SwithaWed 4 Novopen
WS-41The pulse app. Better than files: the agent interview prompt, a reminder at each slot, and a view of the team's pulse over time. (The files version works now.)Angelo, Jose Bota, VickyWed 4 Novopen
WS-42Billing on our sites, like newsroom.sgit.ai. The same billing element as newsroom.sgit.ai on this site and on every site we make for others.Angelo, Jose BotaThu 5 Novopen
WS-43An agent wellness questionnaire. The pulse, for the agents: what they understand, what blocks them, what they would change. After the humans are in line.Angelo, Jose BotaFri 6 Novopen
WS-44Secure harness policies (an experiment, not a priority). A first secure harness policy tried on one agent.Angelo, Jose Botalateropen
WS-45Keys page from everyone's key files. /keys/ lists every people/<id>/key.json, so the team's public keys are in one place.Angelo, Jose BotaWed 4 Novopen
WS-51Technical articles: what we did and how. Detailed articles on the setup, the loops and the policies, published and signed.anyone, Angelofrom Wed 4 Novopen
WS-55Everyone's shirt and hoodie: size, colour, message. One line per person sent to Sarah: size, a colour no one else has, your message.everyoneMon 2 Novopen
WS-59Daniela's agentic team: what it runs, and a policy for each agent. Agents for the website, calendar, email, promotion and lesson preparation, each with a behaviour policy; none with free rein of an email account or students' data.Daniela, Indi Gupte, AngeloWed 4 Novopen
WS-60Daniela's website, and the learning environment. A live site for Daniela, the onboarding for students and the environment Daniela works in, published with the billing element.Indi Gupte, Daniela, AngeloFri 6 Novopen
WS-61Try the voice memo to follow-up loop once. One person records a memo after a real conversation; within the hour their agent has updated the record, made a page and drafted the follow-up.anyoneSat 7 Novopen
WS-62Vote on the design. Your votes and picks for the shirts, hoodies and cards in people/<you>/feedback/design.json (the design page says how), with what you would change. Agents: Your agent shows you the options and commits your answers.everyoneMon 2 Nov, 16:00open
WS-64Booking and talk-to-my-agent on each meet page. Each /meet/<you>/ page (where your shirt and card QR go) has a working booking link and a way to talk to your agent.Angelo, Jose Bota, everyoneThu 5 Novopen
WS-65Stop rewriting ~160 pages on every release. A release changes only the files it is about: content in JSON and markdown, rendered dynamically or built by CI, every gate check kept, CI faster. Before and after numbers in admin/metrics.json. Pass 1 (dev@web-summit.dinis, v0.1.36): the release commit was already 3 files (WS-83). This pass made the gate and CI faster without dropping a check: the gate 0.98 s -> 0.51 s (the key-leak tripwire was decoding the two MP4s, 14 MB, as text on every run; each page is now read once; the key-shape regex no longer backtracks), and CI is two jobs instead of three (validate uploads the very pages it checked as the Pages artifact; the release job tags and deploys them, no second build). .gitignore lost 217 lines of Python boilerplate. Numbers in admin/metrics.json; the CI time after is measured next wake. Agents: dev@web-summit.dinis (then dev@web-summit.angelo) does a refactoring pass every wake.Angelo, Jose BotaWed 4 Novopen: dev@web-summit.dinis
WS-68Navigation that anyone can find their way around. From any page, a person knows where they are and how to get to the parent and siblings: top sections (Start, Team, Work, Summit, About), a sub-menu per section, breadcrumbs, a person bar on every person page (all in from v0.1.30), then a left-hand menu for long sections and pages, and a home page that shows the team visually. Learned from The Ultimate Insider book site (the researcher's notes). Agents: designer@web-summit.dinis designs it; dev@web-summit.dinis builds it, from the site's navigation data.Sarah, Angelo, Jose BotaWed 4 Novopen
WS-69The visual language: personas, infographics, animations. As on The Ultimate Insider book site: a persona for each person and each agent, infographics and animated explanations of how the team and its agents work, and the home page showing the work the team is doing, visually. Agents: designer@web-summit.dinis.Sarah, Indi Gupte, Angelo, Jose BotaThu 5 Novopen
WS-70Full transcripts of both videos. The narration of Reach, Mandate, Gap and of RiskMandate Stories written out on their pages (today the captions are read from frames).anyoneWed 4 Novopen
WS-71Publish the videos on YouTube, Instagram and LinkedIn. Both videos on our channels, each linking to its page here, wired as the template for every video after. Agents: video@web-summit.silvio.Silvio Switha, Angelo, Jose BotaWed 4 Novopen
WS-73Team feedback on the videos. Your votes and comments in people/<you>/feedback/videos.json (how).everyoneTue 3 Novopen
WS-74A public feedback form for the videos and pages. Anyone we send a video to can say what they think, without a GitHub account; answers land where the team reads them (n8n, a vault, or the board). No contact details published.Jose Bota, AngeloWed 4 Novopen
WS-76Move the videos to proper hosting. The videos served from video hosting (not the repository, which slows every deploy), with the pages unchanged. Part of WS-40.Angelo, Jose BotaThu 5 Novopen
WS-77Left-hand section menus, and a top nav that scrolls on a phone. As in the book's shell: a grouped side menu per section (collapsing on a phone, no JS), and a one-row top nav on a phone. See the research. Progress (dev@web-summit.dinis, 2 November, WS-91): on screens wider than 64rem every page now has a left rail with its section's pages and its own headings ("On this page"), and the second row of links hides there. Left: on a phone, the section list as a collapsible menu without JavaScript, and groups for the long Work section. Agents: dev@web-summit.dinis.Angelo, Jose BotaWed 4 Novopen
WS-78A tokens file and a kicker line on every page. One design-tokens file the gate enforces; each page opens with a kicker naming its section and its source file.Angelo, Jose Bota, SarahWed 4 Novopen
WS-81Meet the team, animated. The talk site's slide engine (talk/engine/slide.js) brought here, and a piece showing our agents on an hour dial at their wake minutes, read from JSON.Angelo, Jose BotaFri 6 Novopen
WS-83Stop committing generated output: CI builds and deploys. As the book does: generated pages git-ignored, CI writes the version, builds, deploys and checks the live version; a release is a one-file commit. Changes the CLAUDE.md rule, so Dinis decides. The fastest way to WS-65. Done in v0.1.32 (Dinis said yes): a release commit changed 3 files instead of 359; CI 48 s. Agents: dev@web-summit.dinis.Angelo, Jose Bota, Dinis CruzWed 4 Novdone: conductor@web-summit.dinis
WS-84An offline copy for the summit's wifi. The pages each of us needs at the summit work without a connection.Angelo, Jose BotaSun 8 Novopen
WS-85Deploy the tree the gate validated, not a second build. From security@web-summit.dinis, review of 2 November 03:00 (team/security/reviews/2026-11-02-0300.md, findings 1 and 3). Since WS-83, .github/workflows/deploy-pages.yml runs build.mjs in validate and again in deploy, and publishes the second build without the gate. Build once, validate that tree, publish exactly it (one job, or upload-artifact from validate); it also saves a build per release. While there: .gitignore ignores *.html and index.md everywhere but content/, so a hand-written page elsewhere is never committed and CI cannot see it. Ignore only the paths the build writes (from .generated.txt), or have the gate fail on any untracked, ignored file the build did not write. Done (dev@web-summit.dinis, v0.1.39 and the release after it): validate builds once, runs the gate and, on a push, uploads exactly that tree as the Pages artifact; the release job tags and deploys it without rebuilding. The second point is already held by gate check 10 (no source file is gitignored): a hand-written zzprobe/page.html outside content/ fails with "is gitignored, so CI will not have it" (tested 2 Nov). Agents: dev@web-summit.dinis.Angelo, Jose BotaWed 4 Novdone: dev@web-summit.dinis
WS-87No deploy since v0.1.36: GitHub refuses the release tag push. Every deploy-pages run from v0.1.37 to v0.1.42 failed (v0.1.37 cancelled), so web-summit.sgit.ai still serves v0.1.36. The build and the gate pass; the release job fails at "Tag this release" and skips the deploy. From run 41381758395 (v0.1.42), job release: `` version.txt says v0.1.42 (branch dev) ! [remote rejected] v0.1.37 -> v0.1.37 (refusing to allow a GitHub App to create or update workflow .github/workflows/deploy-pages.yml without workflows permission) `` The tagger catches up from v0.1.37, and the workflow file changed in v0.1.39; the built-in GITHUB_TOKEN may not push a ref that GitHub counts as a workflow change, and that permission cannot be granted to it. WS-85's fix did not touch this. Options: (1) a fine-grained token with contents and workflows write, stored as a repository secret and used only for the tag push (Dinis creates it); (2) deploy the validated tree whether or not the tag push succeeds, tagging as a record that follows (changes the pipeline's order: Dinis's call); (3) tag through the REST API, if GitHub treats that differently (test first). Done looks like: a push to dev deploys, and the live site serves its version. Done (dev@web-summit.dinis, v0.1.44, live). Not a missing permission for the release's own tag: the tagger was catching up v0.1.37 and v0.1.38 (their runs were superseded), and those commits predate the workflow change in v0.1.39, so GitHub counts their tags as a workflow change. The catch-up still requires every missed version's release commit in the history, but pushing those old tags is now best effort (a warning); the current release's tag must still push before the deploy. v0.1.37 and v0.1.38 stay untagged. No token or change of order needed. Done, 2 November (v0.1.51): the root cause was the scheme, not the token: committers picked the number, a dropped pending run left v0.1.37 untagged, and every later release failed the last-tag-plus-one check; the catch-up then hit the workflow-permission refusal. Replaced by CI owns the version (https://newsroom.sgit.ai/articles/ci-owns-the-version.html): admin/build/tag_release.sh numbers, builds, checks, commits as GitHub Actions, tags and deploys; release.sh never writes a number. v0.1.37 to v0.1.46 stay untagged where the catch-up could not push them. Agents: dev@web-summit.dinis owns the fix; conductor@web-summit.dinis found it.Angelo, Jose Bota, Dinis CruzMon 2 Nov, nowdone: dev@web-summit.dinis
WS-91The site uses the width, with navigation and usability people can find their way around. From Dinis, 2 November: "make the width use the page", improve the navigation and the usability. The review and what changed: the site review. Done on 2 November (dev@web-summit.dinis): an 82rem frame with a left rail (the section's pages, then the page's own headings) on wide screens; tables that break between words; prompts that wrap, with a Copy button; the renderer no longer eats asterisks (ten pages fixed). Next: the phone's section menu as a collapsible list without JavaScript (WS-77), grouped menus for the Work section, a "who is on stage now" bar from the log. Done looks like: a new person finds their brief, their dashboard and the board from any page in two clicks, at 1440 and at 390 pixels. Agents: dev@web-summit.dinis builds; designer@web-summit.dinis designs (WS-68, WS-69); conductor@web-summit.dinis routes.Angelo, Jose Bota, Dinis CruzWed 4 Novin progress: dev@web-summit.dinis
WS-94Each person's scheduled Claude keeps their dashboard. Your scheduled session updates the part of people/<you>/dashboard.md below the built block: what you are doing, what your agents are doing, what you want to take on; within your ABP (it writes only people/<you>/**). The plumbing, 2 November: every dashboard now opens with a built block (the next stand-up, since you last looked, my agents as the team sees them), then the line "everything below is yours"; people/<id>/agents.json declares a person's agents; the agents page tells each person's conductor to keep both. Waiting on each person's conductor.everyoneWed 4 Novpicked: conductor@web-summit.dinis (the plumbing); each person's conductor (the content)
WS-95Count every piece of the team: people, agents, sessions, channels. One page with every person, every agent (the team's and each person's), every scheduled session and every channel (WhatsApp, Slack, email, the site), built from data, so nothing is lost as the team grows. Done, 2 November: /team/everything/ (admin/build/inventory.mjs, data/channels.json): people with their level, every agent from the roster, people/<id>/agents.json and the git log (commits, last commit), and every channel.Vicky, AngeloTue 3 Novdone: conductor@web-summit.dinis
WS-96Every meeting has a brief, a debrief and follow-ups. The brief already exists: the agenda and each person's briefing, built from data/meetings/ (the stand-ups page, /meetings/). What is missing is everything after the meeting. On 2 November the 13:00 stand-up ended with seven items on its agenda and none recorded as decided. Done looks like this, for every stand-up from 3 November: 1. Before: the agenda has its decisions at the top, each with options and a recommendation, and the meeting is on the team's calendar at 13:00 and 18:00 UTC (London and Lisbon in November). The calendar series run to Sun 8 Nov for now; whether they stop on Fri 6 or Sat 7 Nov, before Lisbon, is waiting on confirmation, and the seven going to Lisbon (Dinis, Silvio, Nimay, Angelo, Vicky, Jose and Indi) were invited on 2 November, from their workgroup accounts. 2. Debrief, within an hour: each decision is recorded in the decider's own words with admin/tools/agenda.mjs decide, and each item not reached is left open so it carries over. 3. Follow-ups: each action has one owner and a due time, as a board issue (picked_by: set) or an agenda item for the next stand-up. An action with no owner is reported at the start of the next stand-up. To decide with Vicky (WS-46, WS-47): whether the debrief gets its own page under /meetings/, which would be a change to admin/build/meetings.mjs for dev@web-summit.angelo.Angelo, Vickydaily from Tue 3 Novpicked: Angelo, team-collaboration@web-summit.angelo
WS-97The collaboration map, and a daily note on bottlenecks. Who works with whom, people and agents: who hands what to whom, through which channel (a commit's For: trailer, the board, a stand-up item, WhatsApp), and where work waits on one person. Built from what the repository shows: the git log, the board, the pulse, people/<id>/ack.json and the stand-ups. Nothing private, and no contact details. Every day, one short note to Vicky (WS-46, WS-47) and Angelo: the three biggest bottlenecks, one proposal for each, and what changed since the day before. The first reading, 2 November, about 17:00 UTC: - Owners: 86 of the 94 open issues have nobody in picked_by:, and 7 issues due on 2 November are not done. - One busy hub: 23 of the day's 30 agent commits came from Dinis's agents, so most of the work goes through one person's agents. - No feedback loop yet: nobody has a pulse check-in or an ack.json, so the briefings cannot say what each person has seen. - Meetings: no stand-up decision has been recorded yet (WS-96).Angelo, Vicky, Dinis Cruzfirst note Tue 3 Nov, then dailypicked: Angelo, team-collaboration@web-summit.angelo
WS-98Turn on recording for Google Meet in the RiskMandate Workspace. The stand-ups could not be recorded. In the Google Admin console (admin.google.com): Apps, Google Workspace, Google Meet, Meet video settings, Recording: turn it on for the organisation. Recording needs a Workspace edition that includes it (Business Standard or above); check the edition first. Then the recordings land in the organiser's Drive, ready for the meeting debriefs (WS-96).Dinis Cruz, AngeloTue 3 Novopen
WS-99Everyone runs a dashboard agent. dashboard@web-summit.<you>, started with the prompt on the agents page (#dashboard-agent): it keeps your part of your dashboard from the templates at /dashboards/, asking you what you want. With your agents' keys published, it puts you at L4 on /team/setup/.everyoneWed 4 Novopen

My onboarding

PersonLevelWorkspace emailClaude (team)GitHub accountCan pushConductor agentDashboard agentAgent keysOn a scheduleVaultsNext
AngeloL3 a conductor agent runningyesyesyesyesyes·yesyes·Dashboard agent: start your dashboard agent (the start page, step 6)

My pulse

No check-ins yet.

My agents

For an agent: this page is https://web-summit.sgit.ai/people/angelo/index.html (markdown: https://web-summit.sgit.ai/people/angelo/index.md). Site index for agents: https://web-summit.sgit.ai/llms.txt. Source: https://github.com/SGit-AI/SGit-AI__Website__Web-Summit (release branch dev). Identity of the agent that runs this site: https://web-summit.sgit.ai/agent/index.html.