a71af41d9ecf321815f90cce0ca5471152eb56bc
8
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 kristianwindandClaude Opus 5
|
cac6c14a23 |
fix(beskeder): klokkens panel bliver inden for skærmen på en telefon
Panelet hang under klokken med `right: 0` og en fast bredde på 340 px. Klokken sidder ikke yderst — der er en temaknap, et mellemrum og en kantafstand til højre for den — så der er kun omkring 330 px tilbage, og resten blev skubbet ud over venstre kant og klippet af. Målt til -10 px ved en skærmbredde på 390; på en smallere telefon mere. Overskriften "Beskeder" klæbede til kanten uden luft, hvilket er det synlige tegn. På en telefon hører panelet nu til skærmen i stedet for til klokken: det spænder fra kant til kant med en margen i hver side, under toplinjen. Samme knæk ved 820 px som toplinjens egen menuknap, så de to skifter form samtidig. Det får også `overscroll-behavior: contain`, så det at rulle i listen ikke trækker siden bagved med. Toplinjens underkant måles frem for at blive regnet ud. Bredden KUNNE trækkes fra i CSS, men så ville den her fil kende sine naboers størrelse, og den næste knap i toplinjen ville lave fejlen om igen uden at sige noget. --- og fire ustabile prøver mere --- Fladen tegner hver ændring med det samme og sender kaldet bagefter. Alt, man kan se, er altså sandt, før serveren har hørt om det, og en prøve, der genindlæser eller klikker videre i det hul, måler den gamle tilstand. `en monospace-linje kan forlades` ventede 1200 ms før en genindlæsning. Datoprøven ventede 400 ms. Et gæt om, hvor hurtig maskinen er, holder indtil CI er travl — begge fejlede i en fuld kørsel her. `en gruppe er en side med sine projekter` er den mest lærerige: trækket virkede, og `toPass` blev grøn på den lokale tilstand, hvorefter klikket videre hentede en gruppe uden projekter i. Prøvens egen kommentar gætter på et upålideligt HTML5-træk; det var gemningen, der ikke var nået frem. Monospace-prøven havde OVENI en anden fejl, som først viste sig, da den første var lukket: den klikkede "Ny note" og skrev med det samme. `create()` venter på serverens svar, og imens står den forrige notes editor stadig på skærmen, så teksten gik ind i den forrige note og den nye blev tom. Ny hjælper `nyNote()` venter på et tomt felt. Omkring 14 andre steder i filen har samme mønster; de er ikke skrevet om, fordi de består, og en samlet omskrivning ville bytte kendte prøver for ukendte. Det hul findes også for et menneske: klikker man Ny note og skriver straks, lander de første anslag i den forrige note. Det er millisekunder lokalt og sekunder på en dårlig forbindelse. Samme familie som #86, men tiden FØR svaret frem for efter. Noteret som et selvstændigt punkt, ikke rettet her. `noteGemt()` fra #88 er nu `gemt(side, sti)` med noteGemt, opgaveGemt og projektGemt ovenpå. Der står 23 faste ventetider tilbage, men ingen af dem lige før en genindlæsning eller en navigation. Fuld chromium-suite kørt to gange: 90 bestået, 0 fejlet, begge gange. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
kristianwindandClaude Opus 5
|
7f09b35db5 |
feat(projekter): en deling siger til, og der er en vej ud af den
Spørgsmålet var, om modtageren ikke burde godkende først. Svaret er nej — men det, spørgsmålet fik øje på, var rigtigt, og værre end det lød. Tre ting gjaldt samtidig: man blev tilføjet uden at blive spurgt, man fik ikke besked, og man kunne ikke gå ud igen. En delt note gav en klokkebesked; et delt projekt gav ingenting — det stod bare i sidebjælken næste gang, man kiggede, uden at noget sagde hvornår eller fra hvem. Og handleRemoveMember lå bag ejer-kravet, så kun ejeren kunne fjerne nogen, også en selv. Hvert enkelt af de tre er til at leve med. Alle tre sammen gør en deling til noget, der sker for en. Ikke et godkendelsestrin: en invitation, der venter på et ja, betyder, at den, der delte, tror det er gjort, mens arbejdet ligger stille — og noter deles allerede uden. Det, der manglede, var besked og en udgang. `project.shared` er ny. Klokkens follow() kunne allerede føre et project_id hen til projektet, så beskeden bærer sit eget mål og krævede ingen særregel. Ruten til at fjerne et medlem er flyttet ud af ejer-gruppen, og handleren skiller nu de to ting ad: ejeren, der fjerner nogen, og den, der selv går. At pege på en andens medlemskab uden at eje projektet svarer 404 og ikke 403 — "det må du ikke" bekræfter, at medlemskabet findes. Ejeren kan stadig ikke gå fra sit eget projekt; det ville være en overdragelse, og den findes ikke endnu. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
kristianwindandClaude Opus 5
|
6cf184caa6 |
feat(plan): dagens plan står på I dag, og ikke kun i en besked
Planen var en notifikation og ikke andet. Klokken klippede den af efter én linje — "2 forfalder i dag, 1 er sprun…" — og klikket førte ingen steder hen, fordi en plan hverken er en note, en opgave eller et projekt. Det eneste sted, den landede hel, var push-beskeden på telefonen. Nu står den som et kort øverst på I dag, dér hvor man kigger, når man starter dagen. Beskeden er påmindelsen; kortet er stedet, den bliver. Teksten er gemt for dagen frem for regnet forfra, hver gang nogen kigger. En model pr. sidevisning er dyr for noget, der ikke har ændret sig — og vigtigere: en plan, der siger noget andet, når man kigger på den, end den sagde, da den kom, er værre end begge dele hver for sig. Kortet siger også, hvornår den blev lavet: en plan fra klokken syv er en anden slags oplysning klokken fire end klokken otte. En plan fra i går sendes ikke med. Et kort, der viser gårsdagens plan under overskriften "i dag", er værre end et tomt kort. "Forny planen" laver en ny, når dagen har flyttet sig, og sender ikke en besked om noget, man står og kigger på — den slags lærer folk at ignorere klokken. Og for den, der har morgenbeskeden slået fra, tilbyder kortet at lave planen på stedet, så funktionen ikke kun findes for dem, der vil vækkes. Klokken fører nu til I dag, og planen fylder de tre linjer, den er, i stedet for at blive klippet af. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
kristianwindandClaude Opus 5
|
2210dc082a |
feat(opdatering): en ny version siger til, i stedet for at vente på at
blive fundet Tjekket fandtes i forvejen, og svaret stod ét sted: nederst på indstillingssiden for beskeder. Det er en oplysning, man kun får, hvis man i forvejen havde mistanke om, at der var noget at se efter — og "der er kommet en rettelse af noget, du er ramt af" er ikke noget, man gætter sig til at kigge efter. Nu går den i klokken, i push og på mærket på ikonet, som alt andet, der er værd at vide. Og den fører hen, hvor knappen til at genstarte sidder, frem for ud af programmet. Én besked pr. version, ikke én pr. time. En påmindelse hver time om det samme er den slags besked, folk slår fra — og så er den næste, der betyder noget, også slået fra. Versionen, der er sagt til om, skrives først, når beskederne er sendt: den anden vej rundt ville en fejl midtvejs betyde, at halvdelen fik besked og resten aldrig gjorde. Kun administratorer, af samme grund som versionsfeltet allerede er det: en besked om, at serveren er bagud, er en besked om en andens arbejde, hvis man ikke selv kan gøre noget ved den. Og et tjek, operatøren har slået fra, bliver ikke til en besked ad bagvejen. VERDANDE_UPDATE_CHECK styrer det hele, som før. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
kristianwindandClaude Opus 5
|
8139003b35 |
feat(ai): dagens plan, mails der giver mening, og svar på et spørgsmål
De tre sidste af de fem. Alle tre samme sted hen: det, man ellers selv skulle sidde og gøre klokken syv om morgenen. Dagens plan. Én besked om morgenen om det, der forfalder i dag, og det, der er sprunget over. Tallene tælles i basen og gives til modellen som kendsgerninger, den ikke må regne om — en plan, der siger fire opgaver, hvor der er tre, er værre end ingen plan. Er der ingen model, står tallene alene, og det er stadig det, man havde brug for at vide. Er der hverken noget, der forfalder, eller noget, der er sprunget over, kommer der ingen besked: en morgen uden noget at gøre er en god morgen, og en besked om ingenting lærer folk at lade være med at åbne beskeder. Timen er personens egen — klokken syv er syv forskellige steder — og jobbet kører hver time frem for på et klokkeslæt, så en instans, der sov, ikke springer dagen over. Flytter man timen, ryger dagens mærke, så man kan se virkningen i dag i stedet for i morgen. Mails, der giver mening. Opgaven hed, hvad mailen hed: "Anders Jensen: SV: SV: Vedr. levering uge 12". Nok til at genkende, ikke nok til at gøre noget ved. Nu skriver modellen den handling, mailen beder om, og lader være, hvis den ikke beder om nogen. Ét kald pr. gennemløb frem for ét pr. mail — femogtyve mails er ellers femogtyve gange ventetid — og emnet bliver stående i beskrivelsen, så en misforstået mail stadig kan læses. Falder modellen ud, hedder opgaven afsender og emne som før: en model, der er nede, må ikke kunne stoppe posten. Og svar på et spørgsmål. "Hvad lovede jeg Anders i august?" — svaret står spredt over tre noter, og ingen af dem indeholder ordet "lovede". Søgningen kræver, at alle ord optræder, hvilket er rigtigt for et søgefelt og forkert for et spørgsmål, så kandidaterne hentes ord for ord og de noter, flere ord rammer, kommer øverst. Modellen får kun dem: den slår ikke selv noget op, så et svar kan ikke handle om nogen andens noter. Og svaret bærer, hvad det står på — en model, der siger "det gjorde du den 14.", er kun brugbar, hvis man kan slå op i det, den læste det i. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
kristianwindandClaude Opus 5
|
d8f5f6e236 |
feat(noter): nævn en person i en note, og den er delt med dem
At skrive nogens navn i en note *er* at ville have dem til at læse den. Indtil nu var det to handlinger — skriv navnet, åbn panelet, find personen, del — og den anden blev glemt, så noten stod med en besked til en, der ikke kunne se den. Nu deler `@Navn` noten med den, der bliver nævnt, og siger det til dem. Editoren foreslår personer efter `@`, ligesom `#` foreslår projekter. Slået op i navnene frem for tolket ud af teksten. Et navn kan have mellemrum i sig, og et udtryk, der skulle fange dem alle, ville også fange sætningen bagefter: `@Sofie i morgen` ville blive til en person, der hed noget i den retning. Her er der ikke noget at gætte — der står et navn, eller der gør ikke. Det er også dét, der gør det forsvarligt at dele på: adgang må ikke afhænge af, hvor langt et regulært udtryk valgte at læse. En mailadresse er ikke en omtale, det længste navn vinder, og ejefaldets s hører til sætningen. Kun nye omtaler, sammenlignet med teksten før gemningen på samme måde som links: en note gemmes ved hver tastepause, så uden sammenligningen var hver gemning en ny deling og en ny besked om det samme navn. Kun ejerens omtaler deler. En medredaktør må skrive i noten, men ikke give den videre — ellers kunne den, ejeren har delt med, skrive et navn og dermed dele ejerens note med en, ejeren aldrig har hørt om. Det er den samme regel, panelet følger. Læser, ikke medredaktør: en omtale siger "se på det her", og det mindste, der opfylder sætningen, er det rigtige at give. En rolle, ejeren har hævet i panelet, sænkes ikke igen af en omtale. Og én besked pr. handling: den, der lige er blevet nævnt, får "nævnte dig" og ikke også "rettede en note" om den samme gemning. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
kristianwindandClaude Opus 5
|
8ee9fbedfb |
feat(noter): del en note med en, der ikke har en konto endnu
En note kunne deles med dem, der allerede var på instansen — og kun med dem. Skulle en anden læse med, skulle man først invitere dem ind, vente på at de oprettede sig, finde noten frem og så dele den. Fire skridt og en ventetid for det, der er én sætning: lad Sofie se den her. Nu er der ét felt. Man skriver adressen, og serveren ved, om der er en konto bag: er der det, bliver det en deling med det samme, og ellers en invitation, der bliver til delingen i samme øjeblik, kontoen oprettes. Hvem der har en konto, er ikke noget, man skal vide for at dele en note. Rækken er den, der allerede fandtes. En invitation bar i forvejen en e-mail, en rolle og et forseglet token; det eneste, der manglede, var at kunne sige, hvad den var en invitation *til*. note_id ved siden af project_id, med fremmednøglen — dén, der rydder invitationen væk, når noten slettes, inden nogen når at tage imod en invitation til noget, der ikke er der længere. Det er ikke ny magt til nogen: enhver, der ejer et projekt, kunne i forvejen invitere en fremmed ind på instansen pr. e-mail. Kun ejeren kan invitere til en note, som kun ejeren kan dele den. De inviterede står i panelet ved siden af dem, der er kommet, og kan trækkes tilbage. Uden det er en invitation sendt i går usynlig, og så sender man den igen — endnu et link til den samme indbakke, og kun det ene af dem til at gøre ugyldigt. Og delingen siger selv til: den, der får en note delt, får besked om, at den er der. Klokken sorterer nu på id efter tid, fordi tiden er sekunder — en note, der bliver delt og rettet i samme håndbevægelse, stod ellers i den rækkefølge, basen nu engang fandt dem i. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
kristianwindandClaude Opus 5
|
ab77024ec9 |
feat(beskeder): klokken siger til, når nogen rører noget, der er dit
En delt note blev rettet af en anden, og man opdagede det kun ved at åbne den. En opgave blev givet til en, og den lå bare der. Det, andre gør ved det, man deler, skal man kunne se uden at lede efter det. Klokken i hovedet: ulæste beskeder om noter, der er blevet rettet, delt med en, eller opgaver, man har fået. Sætningen skrives i browseren, ikke på serveren, så et engelsk interface får en engelsk klokke. Beskeder om den samme note bliver slået sammen, mens de er ulæste. En note gemmes på en tastepause, så en række pr. gem ville lave én person, der skriver i fem minutter, om til tyve ens linjer. Er beskeden læst, er den næste rettelse en ny ting at få at vide — ikke en gentagelse. note_id får sin egen søjle ved siden af project_id og task_id frem for et generisk (kind, id)-par: de tre er ikke det samme slags nul, og fremmednøglen — dén, der rydder beskeden op, når noten slettes — kan et generisk par ikke have. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |