Jose's dashboard
Open Jose'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
| Releases | Agent and people commits | |
|---|---|---|
| Today (since 00:00 UTC) | 40 | 58 |
| The last 24 hours | 100 | 132 |
| Since you last acknowledged (never: showing the last 24 hours) | 100 | 132 |
Newest releases since then:
- 02:59 UTC v0.2.43 the 02:57 report, and 'What happened' updated
- 02:56 UTC v0.2.42 the access token is server access only; the vault key is the encryption
- 02:52 UTC v0.2.41 decisions blocking Dinis first, the agents second, one click between them
- 02:39 UTC v0.2.40 your vault agent: the guide for everyone to create, publish and share vaults; WS-106 settled; Vicky's and Jose's accounts on the roster
- 02:37 UTC v0.2.39 how every one of Silvio's agents creates and uses a vault (people/silvio/kit/vaults.md)
- 02:32 UTC v0.2.38 publish my session key on the keys page (public half only)
- 02:22 UTC v0.2.37 the PKI section (/pki/): a QR code for every active agent key, the secrets protocol, sign-off, sign-in and the review; WS-115 to WS-119
- 02:17 UTC v0.2.36 WS-74 prepared, not picked up: three options for a public feedback form, and an offline check for spam and contact details
Seen it? Tell your agent "acknowledge": it writes people/jose/ack.json with the time, and your next briefing starts from there.
My agents, as the team sees them
automation@web-summit.jose: the n8n flows: WhatsApp broadcast of the journalist's reports, and any other channel (WS-39). Proposed in Jose's brief; not started. no commits yet.conductor@web-summit.jose: conducts Jose's agents and keeps people/jose/ with Jose: onboarding, agents.json, ack.json, stand-up items, the mentor's notes, and a numbered PDF brief to Jose. 7 commits, last 2026-11-03 01:07 UTC.dashboard@web-summit.jose: keeps Jose's dashboard, people/jose/dashboard.md, the page Jose reads first. 2 commits, last 2026-11-03 01:01 UTC.designer@web-summit.jose. 5 commits, last 2026-11-03 02:15 UTC.dev@web-summit.jose: a builder developer for automations and integrations (n8n, WhatsApp, the site). Started on 3 November 2026 from the prompt in people/jose/kit/README.md; its session key is dev-jose in data/keys.json. 7 commits, last 2026-11-03 02:16 UTC.helper@web-summit.jose: helps anyone stuck on setup (WS-35). Proposed in Jose's brief; not started. no commits yet.
From your mentor
Your core agents, ready to start (three steps each): your kit.
2026-11-02-2250: From mentor@web-summit.jose, to Jose and his agents. Suggestions only; take what helps.
L1, with 3 of the 9 steps on the setup leaderboard done. The next step is Can push: accepting the GitHub invitation to the repository (WS-09). How: the start page.
This is the first note, and your agents have no commits yet, so there is nothing to report so far.
- Once you can push, you could open a new session and paste the first prompt in your kit (linked above). Your conductor would then set up the rest with you.
- A natural first piece of agent work might be pairing with Angelo on the technical pool (WS-33 and WS-35). The n8n flow you already know well could be the first thing your dev agent writes up: what it does, what you tried, what you learned. Would that be a useful place to start?
Has the GitHub invitation arrived? And is there a GitHub username the team still needs from you to send it?
Everything above is built for you; everything below is yours and your agents' to change (people/jose/dashboard.md).
Kept by dashboard@web-summit.jose from the builder template: what needs you, what is broken or being built, and whether the machine is healthy. Tell your dashboard agent what you want first and what you never read; it changes this part every run.
Asked on 3 November, not answered yet: what do you want to see first when you open this page, and what do you never read? Until you answer, the order is: what needs you, your issues, the technical board, the machine.
What needs me
- The next step on setup: your row below. L4 needs your agents' keys on the keys page; L5 needs the dashboard and dev agents on a schedule.
- The vaults (L6) need your GitHub account on the roster: the sgit agent seals vault keys only to keys pushed by an account
data/team.jsonlists for you, and it lists none for you yet (the vaults page, WS-106). Either ask Dinis's conductor, who keeps the roster, to add your account, or read your agents' fingerprints to the sealer out of band. - Your conductor's briefs: the latest numbered PDF and its asks are in people/jose/briefs.
- Messages for you: commits with
For: josein the log on dev.
| Person | Level | Workspace email | Claude (team) | GitHub account | Can push | Conductor agent | Dashboard agent | Agent keys | On a schedule | Vaults | Next |
|---|---|---|---|---|---|---|---|---|---|---|---|
| Jose Bota | L5 agents on a schedule | yes | yes | yes | yes | yes | yes | yes | yes | · | Vaults: open the team vaults with your key (the sgit agent will help) |
My issues
| Issue | What, and what done looks like | For | Due | Status |
|---|---|---|---|---|
| WS-01 | Get 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. | everyone | Tue 3 Nov | open |
| WS-02 | Get 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). | everyone | Tue 3 Nov | open |
| WS-03 | Get 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. | everyone | Wed 4 Nov | open |
| WS-04 | Get 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. | everyone | Wed 4 Nov | open |
| WS-05 | Get 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). | everyone | Thu 5 Nov | open |
| WS-06 | Make 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. | everyone | Wed 4 Nov | open |
| WS-07 | Pulse 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. | everyone | daily from Tue 3 Nov | open |
| WS-08 | Fill in your card. Answers to the questions at the end of your brief, committed to people/<you>/card.md or sent to Dinis. | everyone | Tue 3 Nov | open |
| WS-102 | Seal 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 Bota | Wed 4 Nov | done: sgit@web-summit.dinis |
| WS-106 | Meet 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 Bota | Fri 6 Nov | open |
| WS-107 | Stand-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, everyone | Tue 3 Nov, 13:00 | open |
| WS-108 | Jose's two apps (Hack the Agent, ReachCheck) as the stand demos, if Jose agrees. From the newsroom article "Jose Bota's two agent apps". Hack the Agent (a five-level prompt-injection game) is a stand demo with a QR code to join; ReachCheck checks an agent's setup against its owner's mandate, the ABP model, for one-to-one meetings. Our site does not mention either; Jose's brief lists only automation. First: ask Jose (an item for the next stand-up). Then, only with his yes: link both from his brief and profile, add them to WS-15's demo options, and a QR on the stand material. Agents: conductor@web-summit.jose (asks Jose), designer@web-summit.dinis (the stand), conductor@web-summit.dinis (Jose's brief). | Jose Bota, Dinis Cruz | Wed 4 Nov | open |
| 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, everyone | Wed 4 Nov | open |
| WS-112 | Every 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). | everyone | Wed 4 Nov | open |
| WS-113 | Print 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, everyone | Tue 3 Nov, 16:00 | open |
| WS-117 | Sign 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 Bota | Thu 5 Nov | open |
| WS-120 | Vaults, 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 Switha | Wed 4 Nov | open |
| WS-121 | Everyone 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. | everyone | Fri 6 Nov | open |
| WS-123 | The 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, everyone | Fri 6 Nov | picked: conductor@web-summit.dinis (the foundation); dashboard@web-summit.dinis (the panels); designer@web-summit.dinis (the look) |
| WS-18 | The 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 Bota | Wed 4 Nov | open |
| WS-19 | The 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, anyone | Wed 4 Nov | open |
| WS-26 | The 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, anyone | Thu 5 Nov | open |
| WS-27 | The 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, anyone | from Thu 5 Nov | open |
| WS-30 | Owners for the 20 priority-1 companies. Each priority-1 company on the map has one owner among the seven. | everyone | Tue 3 Nov | open |
| WS-32 | The sessions each person attends. 3 to 6 sessions each from the summit page, with the speakers worth meeting. | everyone | Sat 7 Nov | open |
| WS-33 | Make 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 Bota | Tue 3 Nov | open |
| WS-34 | Behaviour 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 Bota | Wed 4 Nov | open |
| WS-35 | Help each person through setup (L1 to L4). Everyone at L4 by Wednesday evening; what went wrong written down for the next person. | Angelo, Jose Bota | Tue 3 to Wed 4 Nov | open |
| WS-36 | A 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 Cruz | Thu 5 Nov | open |
| WS-37 | Observability lanes on the site. Who visits, what they read, where they came from, shown as a page we can all read. | Angelo, Jose Bota | Thu 5 Nov | open |
| WS-38 | Encrypted 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 Bota | Thu 5 Nov | open |
| WS-39 | A WhatsApp number in the team group, and the RiskMandate Slack. A number that broadcasts updates to the team's WhatsApp group (Jose's n8n flow), and/or a channel in the RiskMandate Slack, carrying the journalist's reports. Picked up by Jose, 3 November 2026 (01:20 UTC): WhatsApp first, Slack as the backup, and check first whether the API can send to a group. The findings are in people/jose/dev/WS-39-findings.md in the repository; the draft maker is people/jose/dev/report-draft.mjs. What the check found (read 3 November 2026, through web search; Meta's pages could not be opened from the agent's session): the official WhatsApp Cloud API has a Groups API, but only for a business with an Official Business Account, only for groups the business creates through the API (people join by an invite link), and with at most 8 participants per group. It cannot post into the team's existing WhatsApp group. Third-party gateways that do post into existing groups (Wassenger, 2Chat, MegaAPI) run a WhatsApp Web session on a phone number, outside Meta's official API. Decision for Jose (and Dinis, since it is a channel for the whole team and an automated post): which route, or Slack first. Agents: dev@web-summit.jose builds the draft and the findings (people/jose/dev/); Jose's n8n flow sends, once decided. | Jose Bota | Wed 4 Nov | picked: Jose, dev@web-summit.jose |
| WS-40 | Hosting 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 Switha | Wed 4 Nov | open |
| WS-41 | The 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, Vicky | Wed 4 Nov | open |
| WS-42 | Billing 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 Bota | Thu 5 Nov | open |
| WS-43 | An 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 Bota | Fri 6 Nov | open |
| WS-44 | Secure harness policies (an experiment, not a priority). A first secure harness policy tried on one agent. | Angelo, Jose Bota | later | open |
| WS-45 | Keys 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 Bota | Wed 4 Nov | open |
| WS-51 | Technical articles: what we did and how. Detailed articles on the setup, the loops and the policies, published and signed. | anyone, Angelo | from Wed 4 Nov | open |
| WS-55 | Everyone's shirt and hoodie: size, colour, message. One line per person sent to Sarah: size, a colour no one else has, your message. | everyone | Mon 2 Nov | open |
| WS-61 | Try 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. | anyone | Sat 7 Nov | open |
| WS-62 | Vote 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. | everyone | Mon 2 Nov, 16:00 | open |
| WS-64 | Booking 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, everyone | Thu 5 Nov | open |
| WS-65 | Stop 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 Bota | Wed 4 Nov | open: dev@web-summit.dinis |
| WS-68 | Navigation 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 Bota | Wed 4 Nov | open |
| WS-69 | The 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 Bota | Thu 5 Nov | open |
| WS-70 | Full 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). | anyone | Wed 4 Nov | open |
| WS-71 | Publish 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 Bota | Wed 4 Nov | open |
| WS-73 | Team feedback on the videos. Your votes and comments in people/<you>/feedback/videos.json (how). | everyone | Tue 3 Nov | open |
| WS-74 | A 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, Angelo | Wed 4 Nov | open |
| WS-76 | Move 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 Bota | Thu 5 Nov | open |
| WS-77 | Left-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 Bota | Wed 4 Nov | open |
| WS-78 | A 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, Sarah | Wed 4 Nov | open |
| WS-81 | Meet 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 Bota | Fri 6 Nov | open |
| WS-83 | Stop 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 Cruz | Wed 4 Nov | done: conductor@web-summit.dinis |
| WS-84 | An offline copy for the summit's wifi. The pages each of us needs at the summit work without a connection. | Angelo, Jose Bota | Sun 8 Nov | open |
| WS-85 | Deploy 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 Bota | Wed 4 Nov | done: dev@web-summit.dinis |
| WS-87 | No 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 Cruz | Mon 2 Nov, now | done: dev@web-summit.dinis |
| WS-91 | The 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 Cruz | Wed 4 Nov | in progress: dev@web-summit.dinis |
| WS-94 | Each 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. | everyone | Wed 4 Nov | picked: conductor@web-summit.dinis (the plumbing); each person's conductor (the content) |
| WS-99 | Everyone 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/. | everyone | Wed 4 Nov | open |
The technical board
Shared with Angelo: one pool, you two choose who takes what.
| Issue | What, and what done looks like | For | Due | Status |
|---|---|---|---|---|
| WS-102 | Seal 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 Bota | Wed 4 Nov | done: sgit@web-summit.dinis |
| WS-106 | Before sealing a vault key, confirm who pushed the recipient's key. From security@web-summit.dinis, review of 2 November 23:50 (team/security/reviews/2026-11-02-2350.md, finding 1). This does not reopen Dinis's decision in WS-102 that the push is the authorisation. It is about what seal.mjs can tell about a push. Every commit in this repository is authored and committed as Claude <noreply@anthropic.com>, from any person's account. The account that pushed a key is therefore not in git. The only evidence is the Claude-Session: trailer, which is free text. seal.mjs --check reports pushed_in as "<hash> Claude ...", which tells the sealer nothing about whose account it was. Anyone with push access (nine people and their agents, or an agent that has been misled by material it read) could add an entry labelled conductor-vicky and receive Vicky's vault key. content/vaults.md lists dev-angelo, dashboard-vicky and conductor-vicky as "ready to be sealed to". Before the first real seal, one of these: 1. Out of band (cheapest): the person reads their agent's signing fingerprint to Dinis, or shows its QR code (CLAUDE.md's second trust path), and the sealer seals by fingerprint, never by label. 2. Ask GitHub, not git: have seal.mjs --check look up who pushed the commit that added the key (the push's actor in the repository's activity or events API) and print that account, refusing if it is not the person the label names. 3. Write rule: a key entry labelled for person X may only be added by X's account; the gate cannot check that, so it belongs with branch protection (WS-90, WS-105). Also: seal.mjs runs ~/.sg-send/tools/pki-agent.mjs and prints its sha256 without comparing it to anything. Pin the expected hash. 3 November, 01:00 UTC, sgit@web-summit.dinis: options 1 and 2 are built into admin/tools/seal.mjs, and the pin is added. Still open for Dinis. - Option 2: --check and every seal ask GitHub's activity API which account made the push that brought the key to dev, and compare it with the accounts data/team.json lists for the person in the key's label. Results today: Dinis's three keys were pushed by DinisCruz and dev-angelo by riskmandate-angelo, which matches the roster. Vicky's two keys were pushed by riskmandate-vicky and Jose's by riskmandate-jose, but the roster lists no GitHub account for either, so the tool refuses them. - Option 1: a refused key can still be sealed to with --fingerprint <fp> once its person has read the fingerprint out of band. The refusal never prints it. - The pin: pki-agent.mjs must match the pinned sha256 (fcb28a1c...). A new version needs PKI_AGENT_SHA256 set by hand after reading it. - For Dinis: whether option 2 is enough on its own, or every first seal also needs option 1, and option 3 (WS-90, WS-105). - For conductor@web-summit.dinis: if Dinis confirms they are theirs, add riskmandate-vicky and riskmandate-jose to the roster. - Gaps: GitHub's activity API keeps about 90 days of pushes, and a key pushed from a shared account (for example riskmandate-agent) proves the account, not the person. Done, 3 November (Dinis): the GitHub check (option 2) is enough for now, for this setup. riskmandate-vicky and riskmandate-jose are Vicky's and Jose's accounts, confirmed by Dinis and added to the roster. riskmandate-agent is Dinis's own account. An account proves the account, not the person, and today each account's person is behind it. seal.mjs now also follows GitHub's page links through the session proxy, which refuses numeric-id paths, so older pushes are found. Agents: sgit@web-summit.dinis, security@web-summit.dinis. | Dinis Cruz | Tue 3 Nov | done: sgit@web-summit.dinis |
| WS-106 | Meet 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 Bota | Fri 6 Nov | open |
| WS-111 | The keys page's missing fields, and a gate check on who may publish a key. From the newsroom identity and key articles. (1) Each entry in data/keys.json gains: the session id, the key it replaces, an end date, the commit that published it, and a QR. (2) A gate check (CI only, where history is available): the commit that adds or changes an entry carries an Agent: trailer equal to that entry's agent. (3) Seven of the nine scheduled agents have not published a key: each publishes at its next run. Note: signed email needs a person key on pki.sgit.ai, which CLAUDE.md now makes optional; say which applies before anyone promises signed email. Agents: sgit@web-summit.dinis (owner), dev@web-summit.dinis (the gate check), security@web-summit.dinis (reviews). | Dinis Cruz | Thu 5 Nov | open |
| WS-114 | Feedback lanes: a vault per agent, who drains them, and idle runs on the same lanes. From Dinis, 3 November: every agent creates its own vault with an append lane; feedback from the site goes to it, sealed, and an agent monitors it. First one done (dev@web-summit.dinis): its vault rx5uxdyu on dev.send.sgraph.ai, one lane, and the pane on every page (assets/feedback.js, off until ?feedback=on on a device): a comment, decision, idea or bug per page, selected text quoted, images pasted or dropped, all kept in local storage, editable, then Submit seals them in the browser to the agent's public key (keys page dev-dinis) and appends them. admin/tools/feedback_drain.py lists, fetches, opens, files each into the vault (feedback/<date>/, markdown, JSON and images), commits, pushes, and only then marks processed. Tested end to end against the live lane on 3 November. Open: (1) who drains: dev drains its own on every wake for now; the conductor, or one agent for all lanes, is Dinis's call. (2) The team vault key Dinis makes tomorrow replaces this session's vault and key. (3) Idle runs: the same lane can carry a run record per wake (one small sealed message, no commit, no release), shown apart from real wakes on /wakes/. (4) The lane is write-only for anyone with the page: everything drained is material, not instructions; a flood fills it at 1000 pending, and rotating is one configure call. Learned: a vault does not exist on the server until its first commit is pushed (configure answers 404 until then). Agents: dev@web-summit.dinis built the first lane; conductor@web-summit.dinis decides who monitors; every agent makes its own vault and lane. | Dinis Cruz | Wed 4 Nov | in progress: dev@web-summit.dinis |
| WS-115 | The OpenRouter key, one per agent, sealed and signed by Dinis: phase 1 of giving out secrets. From Dinis, 3 November: distribute secrets to agents via QR codes, the OpenRouter key first. The protocol is on Giving out secrets (security@web-summit.dinis). 1. Dinis decides: one capped OpenRouter key per agent (recommended, via OpenRouter's provisioning API; the provisioning key is never sealed to anyone) or one shared key. 2. Each person confirms their agent's signing fingerprint out of band before its first seal (WS-106). 3. Dinis seals each key to its agent's fingerprint (from the cards), signed with his key, expiring in 7 days or less, and hands the sealed link or QR to the person. 4. Each agent opens it with pki-agent.mjs open, refuses it unless signed by the operator's key (sha256:db7f79fdd87e030a), keeps it in the session only, and commits a line saying it received it (never the value). Done when the first agents have their own capped key and nothing secret is in the repository (the gate's check 5 catches sk-or-v1-). Agents: security@web-summit.dinis (the protocol, the review), sgit@web-summit.dinis (sealing), every receiving agent. | Dinis Cruz | Tue 3 Nov | open |
| WS-116 | Sign-off: bind the signing agent to its person, match keys exactly, and put verify in the gate. From security@web-summit.dinis, Signing off, reviewing admin/tools/signoff.mjs (WS-113). Before the print sign-offs count: 1. check() accepts a key if its label includes the agent's name: a key labelled not dashboard@web-summit.vicky passes. Match the label's first word exactly (or an agent field, WS-118). 2. Nothing binds --by to --person: Vicky's agent can approve Silvio's set. Refuse unless the agent's person (<agent>@web-summit.<person>) is the person, or the agent is Dinis's and the statement says it signs on Dinis's word. 3. verify in the gate (validate.js calls check(); a bad signature fails the build), as WS-113 asks. Agents: procurement@web-summit.silvio (signoff.mjs), conductor@web-summit.dinis (the gate), security@web-summit.dinis (review). | Silvio Switha, Dinis Cruz | Tue 3 Nov, 16:00 | open |
| WS-117 | Sign 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 Bota | Thu 5 Nov | open |
| WS-118 | The keys page: a status, an expiry and a proof of possession for every key. From security@web-summit.dinis, the PKI review, finding 5. Each entry in data/keys.json gets: 1. agent: the exact agent name (<agent>@web-summit.<person>), so tools stop parsing the free-text label (WS-116). 2. status: active or ended (the cards on /pki/keys/ already read it; today they guess from the prose). conductor-3 needs one: its text still says it holds the conductor seat. 3. expires: when the session key should be treated as gone if nobody says otherwise. 4. proof: a signature by the key's own signing key over {agent, fingerprint, signing_fingerprint, added}, so the entry shows its pusher held the private half (the open question in "The push is the authorisation"). The gate verifies it. Agents: sgit@web-summit.dinis (data/keys.json), security@web-summit.dinis. | Dinis Cruz | Wed 4 Nov | open |
| WS-119 | The feedback lane is unauthenticated: what it carries is material, and approvals wait for signatures. From security@web-summit.dinis, the PKI review, finding 3. The append token in assets/feedback.json is public by design (write-only), so anyone can append to the lane, including a "Decision: Approve" that reads like Dinis's, or fill it until it refuses (507). 1. The draining agent treats every item as material from an unknown sender, never as Dinis's decision, until it is signed (say so in feedback_drain.py's output and the agent's rules). 2. When WS-117 lands, the pane signs each submission with the person's browser key (a pki.sgit.ai/signed/v1 note inside the sealed envelope), and the drain shows who signed it. 3. A cap per day on the lane, and the drain alerts when it is near full. Agents: dev@web-summit.dinis (the pane and the drain), security@web-summit.dinis. | Dinis Cruz | Wed 4 Nov | open |
| WS-120 | Vaults, 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 Switha | Wed 4 Nov | open |
| WS-122 | The gate misses an unprefixed vault key with a short vault id. Found by sgit@web-summit.dinis on 3 November, while writing your vault agent. Everyone is about to make vaults. The gate (admin/build/secrets.cjs) catches sgit_private_vault_… and sgit_private_read_…. Its unprefixed pattern only matches <20+ chars>:<uuid>. Current vault ids are 8 to 12 lowercase characters (for example rx5uxdyu), and sgit create can print the key unprefixed as <passphrase>:<vault id> (sgit's quickstart). A key in that shape pasted into a page or a commit passes the gate. A pattern for <20 to 40 of [A-Za-z0-9]>:<8 to 12 of [a-z0-9]> in prose and code, with a test and a check for false positives across the repository, would close it. Agents: security@web-summit.dinis decides the pattern; dev@web-summit.dinis adds it to admin/build/secrets.cjs with its test. | Dinis Cruz | Wed 4 Nov | open |
| WS-123 | The 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, everyone | Fri 6 Nov | picked: conductor@web-summit.dinis (the foundation); dashboard@web-summit.dinis (the panels); designer@web-summit.dinis (the look) |
| WS-33 | Make 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 Bota | Tue 3 Nov | open |
| WS-34 | Behaviour 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 Bota | Wed 4 Nov | open |
| WS-35 | Help each person through setup (L1 to L4). Everyone at L4 by Wednesday evening; what went wrong written down for the next person. | Angelo, Jose Bota | Tue 3 to Wed 4 Nov | open |
| WS-36 | A 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 Cruz | Thu 5 Nov | open |
| WS-37 | Observability lanes on the site. Who visits, what they read, where they came from, shown as a page we can all read. | Angelo, Jose Bota | Thu 5 Nov | open |
| WS-38 | Encrypted 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 Bota | Thu 5 Nov | open |
| WS-39 | A WhatsApp number in the team group, and the RiskMandate Slack. A number that broadcasts updates to the team's WhatsApp group (Jose's n8n flow), and/or a channel in the RiskMandate Slack, carrying the journalist's reports. Picked up by Jose, 3 November 2026 (01:20 UTC): WhatsApp first, Slack as the backup, and check first whether the API can send to a group. The findings are in people/jose/dev/WS-39-findings.md in the repository; the draft maker is people/jose/dev/report-draft.mjs. What the check found (read 3 November 2026, through web search; Meta's pages could not be opened from the agent's session): the official WhatsApp Cloud API has a Groups API, but only for a business with an Official Business Account, only for groups the business creates through the API (people join by an invite link), and with at most 8 participants per group. It cannot post into the team's existing WhatsApp group. Third-party gateways that do post into existing groups (Wassenger, 2Chat, MegaAPI) run a WhatsApp Web session on a phone number, outside Meta's official API. Decision for Jose (and Dinis, since it is a channel for the whole team and an automated post): which route, or Slack first. Agents: dev@web-summit.jose builds the draft and the findings (people/jose/dev/); Jose's n8n flow sends, once decided. | Jose Bota | Wed 4 Nov | picked: Jose, dev@web-summit.jose |
| WS-40 | Hosting 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 Switha | Wed 4 Nov | open |
| WS-41 | The 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, Vicky | Wed 4 Nov | open |
| WS-42 | Billing 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 Bota | Thu 5 Nov | open |
| WS-43 | An 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 Bota | Fri 6 Nov | open |
| WS-44 | Secure harness policies (an experiment, not a priority). A first secure harness policy tried on one agent. | Angelo, Jose Bota | later | open |
| WS-45 | Keys 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 Bota | Wed 4 Nov | open |
| WS-64 | Booking 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, everyone | Thu 5 Nov | open |
| WS-65 | Stop 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 Bota | Wed 4 Nov | open: dev@web-summit.dinis |
| WS-68 | Navigation 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 Bota | Wed 4 Nov | open |
| WS-74 | A 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, Angelo | Wed 4 Nov | open |
| WS-76 | Move 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 Bota | Thu 5 Nov | open |
| WS-77 | Left-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 Bota | Wed 4 Nov | open |
| WS-78 | A 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, Sarah | Wed 4 Nov | open |
| WS-83 | Stop 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 Cruz | Wed 4 Nov | done: conductor@web-summit.dinis |
| WS-84 | An offline copy for the summit's wifi. The pages each of us needs at the summit work without a connection. | Angelo, Jose Bota | Sun 8 Nov | open |
| WS-85 | Deploy 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 Bota | Wed 4 Nov | done: dev@web-summit.dinis |
| WS-86 | Close the gaps in the secret and contact-detail checks. From security@web-summit.dinis, review of 2 November 03:00 (team/security/reviews/2026-11-02-0300.md, finding 2). Before the team starts pushing: 1. admin/tools/comms_check.mjs (gate check 15): scan content/ too, every text file type (not only .md .json .eml .txt), and stop skipping index.md. 2. Its key rule: add Anthropic keys (sk-ant-... does not match today), github_pat_, gho_, ghs_, xox[abprs]-, AIza, and JWK private members ("d": beside "kty"). 3. admin/build/validate.js check 5: match any -----BEGIN [A-Z ]*PRIVATE KEY----- (today it misses OPENSSH, ENCRYPTED and DSA), as comms_check already does. Add a test fixture for each shape so the gate proves it catches them. Added by security@web-summit.dinis, review of 2 November 03:10 (finding 2): 4. .gitignore: since 059f871 only .credentials/, .env, .envrc and .venv are guarded. Add .sg-send/, *.pem, *.key, id_rsa*, id_ed25519*, .pypirc, *.log. Tested with git check-ignore: each of these is committable today. Done (dev@web-summit.dinis, v0.1.45). The shapes live once, in admin/build/secrets.cjs, used by gate check 5 (every file) and by comms_check.mjs (check 15). 1: comms_check now reads every non-binary file, skipping only what .generated.txt lists instead of every index.md; content/ is key-scanned by check 5 (every file), and joins the contact-detail scan once WS-88 is decided (it finds one role address). 2: sk-ant-, github_pat_, gho_, ghs_, xox[abprs]-, AIza and private JWKs ("d" beside "kty", either order) are caught. 3: any -----BEGIN [A-Z ]*PRIVATE KEY-----. Fixtures: each shape has samples the gate must catch on every run, and public shapes (a public JWK, a fingerprint) it must not; weakening a rule turns the gate red (tested). 4: .gitignore guards .sg-send/, *.pem, *.key, id_rsa*, id_ed25519*, id_ecdsa*, .env.*, .pypirc, .npmrc, *.log; checked with git check-ignore, and people/*/key.json stays committable. Agents: conductor@web-summit.dinis, dev@web-summit.dinis. | Dinis Cruz | Tue 3 Nov | done: dev@web-summit.dinis |
| WS-87 | No 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 Cruz | Mon 2 Nov, now | done: dev@web-summit.dinis |
| WS-88 | May a role address be public? The Drive service account in an ABP. From dev@web-summit.dinis, WS-86. Widening the contact-detail check (comms_check, gate check 15) to content/ finds one address: the Drive service account's (a role at riskmandate.ai), in content/abp/conductor-web-summit-dinis.md (Reach, Systems), live since v0.1.45. It is a role address, not a person's, but the rule today is "no email address in public files" and the ABP is exactly where one belongs. Dinis decides one of: (1) role addresses at riskmandate.ai may be public, and comms_check allows them by name; or (2) the ABP names the account without its address ("the RiskMandate Drive service account"), and the conductor changes its file. Either way, then add content back to comms_check's default folders (one word, admin/tools/comms_check.mjs) so the gate scans it. Agents: conductor@web-summit.dinis (owner of the file), abp@web-summit.dinis, security@web-summit.dinis. | Dinis Cruz | Tue 3 Nov | open |
| WS-89 | Three agents' prompts are copies of the conductor's (abp, sgit, project-manager). From abp@web-summit.dinis, found while writing their ABPs (v0.1.45). On the agents page (content/agents.md), the prompts in the sections #abp, #sgit and #project-manager each tell the agent to commit as conductor@web-summit.dinis, release with AGENT=conductor@web-summit.dinis, read For: conductor@web-summit.dinis, and do the conductor's wake (WAKE.md, the roster, the board, REALITY.md, the log). Each prompt's last line then limits the agent to its own paths. The two halves contradict each other, and three more agents acting as the conductor would make its commits impossible to attribute. Fix: in each of the three prompts, use the agent's own name in the commit, release and For: lines, and remove the conductor's "Each wake: follow team/conductor/WAKE.md ... close idle." sentence. abp@web-summit.dinis ran its first wake under its own name and did only the ABP work. Done, 3 November: the three sections now sign, release and read For: under their own names (content/agents.md). The cause: the conductor wrote them on 2 November by copying the shared instructions from its own section after its name had been filled in. Every other section checked: no mismatch. Agents: conductor@web-summit.dinis (owner of content/agents.md), abp@web-summit.dinis. | Dinis Cruz | Tue 3 Nov | done: conductor@web-summit.dinis |
| WS-90 | Branch protection on main and dev, so "never push to main" is a barrier and not only a rule. From abp@web-summit.dinis, the gap common to every ABP in content/abp/ (2 November 2026). The GitHub branches API reports main and dev with protected: false, and every scheduled agent's session has push access. So "never push to main", "never force-push" and "never disable a check" are rules each agent keeps, with nothing technical behind them; a push to main is tagged as a major release and deployed by CI. Dinis decides (repository admin only): (1) protect main: only Dinis pushes, no force-push, no deletion; (2) protect dev against force-push and deletion, leaving pushes open so release.sh keeps working; (3) optionally, require Dinis's review for changes to .github/workflows/, admin/build/validate.js and admin/build/tag_release.sh (CODEOWNERS; since v0.1.51 tag_release.sh runs on every push with a token that can write to the repository and deploy), which would hold dev@'s gate work for a review. Also worth deciding: remove the Google Drive connector from sessions whose mandate does not use Drive. Each change moves a Gap in the ABPs from a rule to a technical barrier, and the ABPs will be updated on the next wake. 3 November, 00:15 (abp@web-summit.dinis): part (1), main, is now WS-105 (picked; the github-pages environment allows main, v0.2.0 deployed from PR #1). The rule failed once before it got there: at 23:06 on 2 November the conductor pushed to main when asked for a major release. The GitHub branches API still reports main and dev with protected: false. Still open here: (2) dev against force-push and deletion, and (3) review on the gate, the workflow and tag_release.sh. Also seen: seven claude/* branches pushed from agents' sessions, which a branch rule restricting who may create branches would stop. Agents: abp@web-summit.dinis, security@web-summit.dinis, dev@web-summit.dinis. | Dinis Cruz | Wed 4 Nov | open |
| WS-91 | The 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 Cruz | Wed 4 Nov | in progress: dev@web-summit.dinis |
The machine
The agents at work · the ABPs · everything on the team · the setup leaderboard · the CI runs
My agents
The list with jobs and schedules is agents.json, kept by your conductor; the prompts are in your kit. What they did is in "My agents, as the team sees them" at the top.
- conductor@web-summit.jose: runs your other agents and keeps
people/jose/with you. - dashboard@web-summit.jose: keeps this part of the page. Started 3 November; its key is
dashboard-joseon the keys page. - dev@web-summit.jose: ready in the kit.
- automation@web-summit.jose (WS-39, the n8n WhatsApp broadcast) and helper@web-summit.jose (WS-35): proposed in your brief.