dogfather-universe

1,028 Commits 2 Branches 0 Tags

3 Commits

Include renames

Author	SHA1	Message	Date
DogFatherGitandClaude Opus 5	d85694bd92	Keine fertigen Vorschläge mehr bei den Highlights Filipe: "nimm die sachen da weg bitte. da sollen nur die sachen rein kommen die die modis, linke und rechte hand oder dogfather reinsetzen." In der Spalte "Noch einzusortieren" standen drei vorgefertigte Vorschlaege ("Was hier hingehoert", "Fanart von DogFather und Casper ist ausdruecklich erwuenscht", "Ein Ausschnitt, der auf die Clips soll"). Jemand hatte sie uebernommen, und danach standen sie zwischen den echten Clips -- mit Datum, mit Verfasser, aeusserlich nicht von einem echten Eintrag zu unterscheiden. WARUM DIESES BRETT ANDERS IST ALS DIE UEBRIGEN: Anderswo ist ein Vorschlag eine ANREGUNG, die man ausfuellt ("Der naechste Stream mit DogFather" -> Datum eintragen). Highlights ist eine SAMMLUNG echter Sachen. Ein vorgefertigter Text ist dort kein Anfang, sondern ein Platzhalter, der aussieht wie Inhalt. Die anderen Bretter behalten ihre Vorschlaege -- dazu hat er nichts gesagt. Nebenbefund: Seine Rollenaufzaehlung ist genau TREFF_TEAM_ROLLEN (modi, hand, linke, admin). Die Rechteregel stimmte also schon. ZWEI ECHTE MAENGEL FIELEN DABEI AUF, beide beim Versuch, die drei Eintraege wegzunehmen: 1. Der Knopf "loeschen" schickte DELETE OHNE GRUND. Der Server verlangt bei einem fremden Beitrag auf einem Treff-Brett einen (DSA Art. 17) und antwortet mit 400 -- die Oberflaeche zeigte nur "Loeschen hat nicht geklappt." Zwei Knoepfe nebeneinander, einer ging ("entfernen"), einer nicht, und die Meldung erklaerte nichts. Jetzt fragt auch "loeschen" nach dem Grund, wenn der Server einen braucht -- erkannt an `treffBrett` vom Server, nicht an einer abgeschriebenen Brettliste -- und die Fehlermeldung gibt wieder, was der Server gesagt hat. 2. Der Dialog liess DREI Zeichen als Grund durch, der Server verlangt ZEHN. Wer "spam" tippte, kam durch die Nachfrage und bekam danach eine Absage. `grund_min` steht seit dem 11.09. in /api/treff/lage und wurde nie benutzt; jetzt ist es angeschlossen. In nachfrage.js bestimmt der Aufrufer die Mindestlaenge (`grundMin`), Vorgabe bleibt 3 -- fuer alle anderen Nachfragen aendert sich nichts. UND ZWEI PRUEFUNGEN, DIE ROT WAREN, OHNE DASS ETWAS KAPUTT WAR: - pruef-treff-start verlangte `>= 8` Vorschlaege auf dem Schirm. Das stimmte bis zum Fenster-Umbau vom 20.09. -- seither kommen hoechstens VIER (FENSTER = 4). Vier Tage rot, ohne dass es jemand erfuhr. Gefragt wird jetzt der Server selbst. Und die Brettliste ["treff","anschlag","wunsch","highlight"] wird gegen den Bestand abgeglichen statt abgeschrieben -- mit ausdruecklichem Nachweis, dass Highlights keine mehr hat, damit das Wegfallen nicht einfach eine Pruefung weniger bedeutet. 41 -> 42 Pruefungen. - pruef-nachfrage zaehlte `installieren.js` als "diese Seite fragt nach", obwohl der Aufruf dort hinter `if (typeof window.frageNach === 'function')` steht. Weil die Datei auf fast jeder Seite liegt, wurde damit JEDE Seite zur fragenden -- fuenf rote Zeilen, kein einziger echter Mangel. Ausserdem wurde die Kurzschreibweise `{ titel, … }` als "ohne Titel" gemeldet. 46 -> 53 Pruefungen, alle gruen; zwei davon sind neu (Gegenprobe plus Benennung der Ausnahmen). Beide mit Gegenprobe (git stash) belegt: schon vor dieser Aenderung rot. Gemessen: 11 Messungen, 0 Befunde -- darunter die Gegenprobe, dass der alte Weg (DELETE ohne Grund) wirklich mit 400 gescheitert waere. Gruen: pruef-treff-start (42), pruef-nachfrage (53), pruef-highlights (31), pruef-anschlagbrett (12), pruef-css-klassen. Co-Authored-By: Claude Opus 5 <[email protected]>	2026-09-24 00:50:42 +02:00
DogFatherGit	cc39552b4f	Eine Eingabe geht nicht mehr wortlos verloren Filipe: "Was passiert, wenn jemand eine Funktion abbricht?" GEMESSEN: Acht Dialoge im Workspace enthalten Eingabefelder -- "Aufgabe bearbeiten" (10 Felder), der Tageseintrag in der Leistung (8), Ziele, Netzwerk, Import, ein neuer Chat-Raum, ein Creator. Bei allen galt: Esc, Klick daneben oder "Abbrechen" wirft ALLES weg, wortlos. Wer zehn Felder ausgefuellt hat und mit dem Daumen den Rand trifft, faengt von vorn an. Neu: window.verwurfWache() in nachfrage.js. BEIDE SCHLIESSWEGE, denn sie laufen verschieden: Esc / Klick daneben loest `cancel` aus, close() wird NICHT gerufen "Abbrechen"-Knopf ruft close(), loest kein `cancel` aus Wer nur einen abfaengt, hat eine halbe Sicherung -- und die ist schlimmer als keine, weil man ihr vertraut. NICHT VON HAND VERTEILT: Jeder Dialog mit Feldern bekommt sie automatisch (ausser dem Nachfrage-Dialog selbst -- er wuerde beim Schliessen nach sich selbst fragen, in sich selbst, und haenge fuer immer). Wer morgen einen neunten baut, hat sie, ohne daran zu denken. UND SIE FRAGT NUR BEI WIRKLICHER AENDERUNG. Beim Oeffnen wird ein Abbild der Felder genommen, beim Schliessen verglichen. Wer einen Dialog aufmacht und gleich wieder zu, merkt nichts. ZWEI SACHEN BEIM BAUEN GEMESSEN STATT VERMUTET: MEINE EIGENE "ROBUSTHEIT" HAT DIE WACHE STILL AUSGESCHALTET. Gegen den Fall "Felder werden erst nach dem Oeffnen gefuellt" hatte ich einen zweiten Schnappschuss beim Hineinklicken (`focusin`) eingebaut. Gemessen: Der entstand NACH dem Tippen -- Fokus und Werteingabe passieren im selben Atemzug. `beimOeffnen` war danach gleich dem getippten Text, und der Dialog ging wortlos zu. Die Sicherung sah eingebaut aus und tat nichts. Jetzt wird im naechsten BILD nachgetragen: Was das Skript beim Oeffnen nachtraegt, ist drin; getippt haben kann in derselben Sechzehntelsekunde niemand. (Nachgemessen: Alle acht Dialoge fuellen heute VOR showModal.) ZWEIMAL ESC HINTEREINANDER SCHLIESST TROTZDEM. Das ist Chromiums "close watcher": Eine Seite darf den Nutzer nicht mit Esc einsperren. Die Regel ist richtig; dagegen anzubauen waere falsch. Sie steht deshalb im Code und in der Pruefung -- festgehalten, nicht umgangen. Der Knopf unterliegt ihr nicht, und am Handy gibt es ohnehin kein Esc. Elf Speicherwege rufen `vergessen()`, damit nach erfolgreichem Speichern nicht gefragt wird. Eine Warnung nach dem Speichern waere genau die, die man wegklickt -- und danach auch die echte. pruef-nachfrage 49/0 (war 33), davon zehn am Bildschirm: unberuehrt geht er ohne Nachfrage zu nach einer Aenderung fragt Esc nach, der Dialog bleibt offen "Weiter bearbeiten" laesst ihn offen UND der Text steht noch da auch der Abbrechen-Knopf fragt -- jedes Mal "Verwerfen" schliesst wirklich, und der Text steht nirgends pruef-aufgabenbrett, -leistung, -uebersicht-browser, -chat-optik, -css-klassen gruen, pruef-tippziele 11/0.	2026-09-20 15:11:25 +02:00
DogFatherGit	c516aad4ed	Nichts verschwindet mehr ohne eine Nachfrage, die sagt was passiert Filipe: "Es darf vor allem keine Stellen geben, an denen ein Benutzer etwas falsch machen kann, nur weil die Seite es nicht verstaendlich genug erklaert." Gemessen: 30 Stellen in 16 Dateien benutzten confirm() oder prompt(). Das Haus hatte die richtige Bauweise laengst -- einen <dialog>, in aufgaben.html sogar ausfuehrlich begruendet -- aber sie stand IN EINER SEITE. Wer anderswo etwas loeschen liess, hatte sie nicht. confirm('Wirklich loeschen?') stellt die falsche Frage: Es fragt, ob man sicher ist, und nennt nicht, WAS passiert, was BLEIBT und ob es ZURUECK geht. Jetzt beantwortet jeder der 41 Dialoge alle drei. Neu: workspace/assets/js/nachfrage.js -- window.frageNach() mit Pflichtgrund, Zahlenfeld, einzeiliger Eingabe und Abtippsicherung. Drei Ausgaenge: <dialog> / confirm()-Notnagel fuer Safari vor 15.4 / Abbruch (Esc, Klick daneben, "Doch nicht" -- immer false). DREIMAL DERSELBE FALLSTRICK, dreimal nachgemessen statt vermutet: .dialog stand in aufgaben.css und leistung.css -> auf dateien.html waere der Dialog ein weisser Systemkasten gewesen. 14 Regeln klammergenau nach module.css verschoben (Klammern gezaehlt, nicht per Muster geschnitten -- heute frueh hat ein nicht-gieriges Muster schon einmal CSS zerrissen). Das Formular trug .neu neu--blank -- und .neu gibt seine Abstaende nur in aufgaben.css. Gemessen: padding 0px, und die Felder verloren ihre height:44px. Jetzt steht alles unter .nachfrage__form in module.css; der Dialog borgt nichts mehr. Die erste Fassung der Pruefung zaehlte nachfrage.js SELBST als Nutzer -- damit war jede Seite trivialerweise "Nutzer" und die Pruefung gruen ohne Inhalt. Jetzt ausdruecklich ausgenommen. ZWEI FUNDE NEBENBEI: hilfeAufraeumen() wird im Betrieb NIE aufgerufen. Der Kommentar behauptete "wird beim Start aufgerufen (siehe index.js)" -- das war nie wahr; einziger Aufrufer ist die eigene Pruefung. Folge: geschlossene vertrauliche Faelle bleiben unbegrenzt stehen. NICHT eingeschaltet (das loescht echte Daten und ist Filipes Entscheidung), sondern der Kommentar richtiggestellt. Einen Hilfe-Fall zu schliessen ist endgueltig -- es gibt keine Route, die ihn wieder oeffnet. Vorher stand darueber nur die Frage nach einem Schlusswort. Jetzt sagt der Dialog es. pruef-struktur hat meine eigene Pruefung von heute Nachmittag erwischt: Sie bildete ihr Datum aus UTC. Beim Beheben erst heuteLokal(datum) genommen -- die Funktion nimmt gar kein Argument und haette still "heute" statt "+3 Tage" geliefert. Jetzt tagLokal(3), nachgerechnet: Abstand 3 Tage. Am Bildschirm angesehen (Rechner 1280, Handy 390): passt rein, Esc ergibt false, Fokus liegt auf dem harmlosen Knopf, Knoepfe 44px auf Touch. Der Platzhalter im Abtippfeld zeigte den erwarteten Namen -- das sah aus wie ein schon ausgefuelltes Feld, entfernt. Neu: server/pruef-nachfrage.mjs -- 17/0, mit sechs Gegenproben und beiden Richtungen (wer fragt, laedt die Datei; wer nie fragt, laedt sie nicht -- sonst truege die Anmeldewand 4,8 KB fuer nichts). pruef-meldungen 8/0, pruef-css-klassen gruen, pruef-struktur gruen, pruef-leistung gruen.	2026-09-19 19:57:43 +02:00

Author

SHA1

Message

Date

DogFatherGitandClaude Opus 5

d85694bd92

Keine fertigen Vorschläge mehr bei den Highlights

Filipe: "nimm die sachen da weg bitte. da sollen nur die sachen rein
kommen die die modis, linke und rechte hand oder dogfather
reinsetzen."

In der Spalte "Noch einzusortieren" standen drei vorgefertigte
Vorschlaege ("Was hier hingehoert", "Fanart von DogFather und Casper
ist ausdruecklich erwuenscht", "Ein Ausschnitt, der auf die Clips
soll"). Jemand hatte sie uebernommen, und danach standen sie zwischen
den echten Clips -- mit Datum, mit Verfasser, aeusserlich nicht von
einem echten Eintrag zu unterscheiden.

WARUM DIESES BRETT ANDERS IST ALS DIE UEBRIGEN: Anderswo ist ein
Vorschlag eine ANREGUNG, die man ausfuellt ("Der naechste Stream mit
DogFather" -> Datum eintragen). Highlights ist eine SAMMLUNG echter
Sachen. Ein vorgefertigter Text ist dort kein Anfang, sondern ein
Platzhalter, der aussieht wie Inhalt. Die anderen Bretter behalten
ihre Vorschlaege -- dazu hat er nichts gesagt.

Nebenbefund: Seine Rollenaufzaehlung ist genau TREFF_TEAM_ROLLEN
(modi, hand, linke, admin). Die Rechteregel stimmte also schon.

ZWEI ECHTE MAENGEL FIELEN DABEI AUF, beide beim Versuch, die drei
Eintraege wegzunehmen:

1. Der Knopf "loeschen" schickte DELETE OHNE GRUND. Der Server
   verlangt bei einem fremden Beitrag auf einem Treff-Brett einen
   (DSA Art. 17) und antwortet mit 400 -- die Oberflaeche zeigte nur
   "Loeschen hat nicht geklappt." Zwei Knoepfe nebeneinander, einer
   ging ("entfernen"), einer nicht, und die Meldung erklaerte nichts.
   Jetzt fragt auch "loeschen" nach dem Grund, wenn der Server einen
   braucht -- erkannt an `treffBrett` vom Server, nicht an einer
   abgeschriebenen Brettliste -- und die Fehlermeldung gibt wieder,
   was der Server gesagt hat.

2. Der Dialog liess DREI Zeichen als Grund durch, der Server verlangt
   ZEHN. Wer "spam" tippte, kam durch die Nachfrage und bekam danach
   eine Absage. `grund_min` steht seit dem 11.09. in /api/treff/lage
   und wurde nie benutzt; jetzt ist es angeschlossen. In nachfrage.js
   bestimmt der Aufrufer die Mindestlaenge (`grundMin`), Vorgabe
   bleibt 3 -- fuer alle anderen Nachfragen aendert sich nichts.

UND ZWEI PRUEFUNGEN, DIE ROT WAREN, OHNE DASS ETWAS KAPUTT WAR:

- pruef-treff-start verlangte `>= 8` Vorschlaege auf dem Schirm. Das
  stimmte bis zum Fenster-Umbau vom 20.09. -- seither kommen
  hoechstens VIER (FENSTER = 4). Vier Tage rot, ohne dass es jemand
  erfuhr. Gefragt wird jetzt der Server selbst. Und die Brettliste
  ["treff","anschlag","wunsch","highlight"] wird gegen den Bestand
  abgeglichen statt abgeschrieben -- mit ausdruecklichem Nachweis,
  dass Highlights keine mehr hat, damit das Wegfallen nicht einfach
  eine Pruefung weniger bedeutet. 41 -> 42 Pruefungen.

- pruef-nachfrage zaehlte `installieren.js` als "diese Seite fragt
  nach", obwohl der Aufruf dort hinter `if (typeof window.frageNach
  === 'function')` steht. Weil die Datei auf fast jeder Seite liegt,
  wurde damit JEDE Seite zur fragenden -- fuenf rote Zeilen, kein
  einziger echter Mangel. Ausserdem wurde die Kurzschreibweise
  `{ titel, … }` als "ohne Titel" gemeldet. 46 -> 53 Pruefungen, alle
  gruen; zwei davon sind neu (Gegenprobe plus Benennung der
  Ausnahmen).

Beide mit Gegenprobe (git stash) belegt: schon vor dieser Aenderung
rot.

Gemessen: 11 Messungen, 0 Befunde -- darunter die Gegenprobe, dass
der alte Weg (DELETE ohne Grund) wirklich mit 400 gescheitert waere.
Gruen: pruef-treff-start (42), pruef-nachfrage (53), pruef-highlights
(31), pruef-anschlagbrett (12), pruef-css-klassen.

Co-Authored-By: Claude Opus 5 <[email protected]>

2026-09-24 00:50:42 +02:00

DogFatherGit

cc39552b4f

Eine Eingabe geht nicht mehr wortlos verloren

Filipe: "Was passiert, wenn jemand eine Funktion abbricht?"

GEMESSEN: Acht Dialoge im Workspace enthalten Eingabefelder --
"Aufgabe bearbeiten" (10 Felder), der Tageseintrag in der Leistung
(8), Ziele, Netzwerk, Import, ein neuer Chat-Raum, ein Creator. Bei
allen galt: Esc, Klick daneben oder "Abbrechen" wirft ALLES weg,
wortlos. Wer zehn Felder ausgefuellt hat und mit dem Daumen den Rand
trifft, faengt von vorn an.

Neu: window.verwurfWache() in nachfrage.js.

BEIDE SCHLIESSWEGE, denn sie laufen verschieden:
  Esc / Klick daneben  loest `cancel` aus, close() wird NICHT gerufen
  "Abbrechen"-Knopf    ruft close(), loest kein `cancel` aus
Wer nur einen abfaengt, hat eine halbe Sicherung -- und die ist
schlimmer als keine, weil man ihr vertraut.

NICHT VON HAND VERTEILT: Jeder Dialog mit Feldern bekommt sie
automatisch (ausser dem Nachfrage-Dialog selbst -- er wuerde beim
Schliessen nach sich selbst fragen, in sich selbst, und haenge fuer
immer). Wer morgen einen neunten baut, hat sie, ohne daran zu denken.

UND SIE FRAGT NUR BEI WIRKLICHER AENDERUNG. Beim Oeffnen wird ein
Abbild der Felder genommen, beim Schliessen verglichen. Wer einen
Dialog aufmacht und gleich wieder zu, merkt nichts.

ZWEI SACHEN BEIM BAUEN GEMESSEN STATT VERMUTET:

  MEINE EIGENE "ROBUSTHEIT" HAT DIE WACHE STILL AUSGESCHALTET.
  Gegen den Fall "Felder werden erst nach dem Oeffnen gefuellt" hatte
  ich einen zweiten Schnappschuss beim Hineinklicken (`focusin`)
  eingebaut. Gemessen: Der entstand NACH dem Tippen -- Fokus und
  Werteingabe passieren im selben Atemzug. `beimOeffnen` war danach
  gleich dem getippten Text, und der Dialog ging wortlos zu. Die
  Sicherung sah eingebaut aus und tat nichts.
  Jetzt wird im naechsten BILD nachgetragen: Was das Skript beim
  Oeffnen nachtraegt, ist drin; getippt haben kann in derselben
  Sechzehntelsekunde niemand.
  (Nachgemessen: Alle acht Dialoge fuellen heute VOR showModal.)

  ZWEIMAL ESC HINTEREINANDER SCHLIESST TROTZDEM. Das ist Chromiums
  "close watcher": Eine Seite darf den Nutzer nicht mit Esc
  einsperren. Die Regel ist richtig; dagegen anzubauen waere falsch.
  Sie steht deshalb im Code und in der Pruefung -- festgehalten,
  nicht umgangen. Der Knopf unterliegt ihr nicht, und am Handy gibt
  es ohnehin kein Esc.

Elf Speicherwege rufen `vergessen()`, damit nach erfolgreichem
Speichern nicht gefragt wird. Eine Warnung nach dem Speichern waere
genau die, die man wegklickt -- und danach auch die echte.

pruef-nachfrage 49/0 (war 33), davon zehn am Bildschirm:
  unberuehrt geht er ohne Nachfrage zu
  nach einer Aenderung fragt Esc nach, der Dialog bleibt offen
  "Weiter bearbeiten" laesst ihn offen UND der Text steht noch da
  auch der Abbrechen-Knopf fragt -- jedes Mal
  "Verwerfen" schliesst wirklich, und der Text steht nirgends

pruef-aufgabenbrett, -leistung, -uebersicht-browser, -chat-optik,
-css-klassen gruen, pruef-tippziele 11/0.

2026-09-20 15:11:25 +02:00

DogFatherGit

c516aad4ed

Nichts verschwindet mehr ohne eine Nachfrage, die sagt was passiert

Filipe: "Es darf vor allem keine Stellen geben, an denen ein Benutzer
etwas falsch machen kann, nur weil die Seite es nicht verstaendlich
genug erklaert."

Gemessen: 30 Stellen in 16 Dateien benutzten confirm() oder prompt().
Das Haus hatte die richtige Bauweise laengst -- einen <dialog>, in
aufgaben.html sogar ausfuehrlich begruendet -- aber sie stand IN EINER
SEITE. Wer anderswo etwas loeschen liess, hatte sie nicht.

confirm('Wirklich loeschen?') stellt die falsche Frage: Es fragt, ob
man sicher ist, und nennt nicht, WAS passiert, was BLEIBT und ob es
ZURUECK geht. Jetzt beantwortet jeder der 41 Dialoge alle drei.

Neu: workspace/assets/js/nachfrage.js -- window.frageNach() mit
Pflichtgrund, Zahlenfeld, einzeiliger Eingabe und Abtippsicherung.
Drei Ausgaenge: <dialog> / confirm()-Notnagel fuer Safari vor 15.4 /
Abbruch (Esc, Klick daneben, "Doch nicht" -- immer false).

DREIMAL DERSELBE FALLSTRICK, dreimal nachgemessen statt vermutet:
  .dialog stand in aufgaben.css und leistung.css -> auf dateien.html
    waere der Dialog ein weisser Systemkasten gewesen. 14 Regeln
    klammergenau nach module.css verschoben (Klammern gezaehlt, nicht
    per Muster geschnitten -- heute frueh hat ein nicht-gieriges
    Muster schon einmal CSS zerrissen).
  Das Formular trug .neu neu--blank -- und .neu gibt seine Abstaende
    nur in aufgaben.css. Gemessen: padding 0px, und die Felder
    verloren ihre height:44px. Jetzt steht alles unter
    .nachfrage__form in module.css; der Dialog borgt nichts mehr.
  Die erste Fassung der Pruefung zaehlte nachfrage.js SELBST als
    Nutzer -- damit war jede Seite trivialerweise "Nutzer" und die
    Pruefung gruen ohne Inhalt. Jetzt ausdruecklich ausgenommen.

ZWEI FUNDE NEBENBEI:
  hilfeAufraeumen() wird im Betrieb NIE aufgerufen. Der Kommentar
    behauptete "wird beim Start aufgerufen (siehe index.js)" -- das
    war nie wahr; einziger Aufrufer ist die eigene Pruefung. Folge:
    geschlossene vertrauliche Faelle bleiben unbegrenzt stehen. NICHT
    eingeschaltet (das loescht echte Daten und ist Filipes
    Entscheidung), sondern der Kommentar richtiggestellt.
  Einen Hilfe-Fall zu schliessen ist endgueltig -- es gibt keine
    Route, die ihn wieder oeffnet. Vorher stand darueber nur die
    Frage nach einem Schlusswort. Jetzt sagt der Dialog es.

pruef-struktur hat meine eigene Pruefung von heute Nachmittag
erwischt: Sie bildete ihr Datum aus UTC. Beim Beheben erst
heuteLokal(datum) genommen -- die Funktion nimmt gar kein Argument
und haette still "heute" statt "+3 Tage" geliefert. Jetzt tagLokal(3),
nachgerechnet: Abstand 3 Tage.

Am Bildschirm angesehen (Rechner 1280, Handy 390): passt rein, Esc
ergibt false, Fokus liegt auf dem harmlosen Knopf, Knoepfe 44px auf
Touch. Der Platzhalter im Abtippfeld zeigte den erwarteten Namen --
das sah aus wie ein schon ausgefuelltes Feld, entfernt.

Neu: server/pruef-nachfrage.mjs -- 17/0, mit sechs Gegenproben und
beiden Richtungen (wer fragt, laedt die Datei; wer nie fragt, laedt
sie nicht -- sonst truege die Anmeldewand 4,8 KB fuer nichts).

pruef-meldungen 8/0, pruef-css-klassen gruen, pruef-struktur gruen,
pruef-leistung gruen.

2026-09-19 19:57:43 +02:00