Start / Über mich
Über mich
Warum diesem Record zu trauen ist: wie ich denke, wie ich hierhergekommen bin und warum ich die Arbeit offen veröffentliche.
Ich bin Sean Duncombe. Ich entwerfe und baue maßgeschneiderte KI-Workflows und die internen Systeme, auf denen Unternehmen still und leise laufen – Terminplanung, Automatisierung und Google-Workspace-Integrationen – über meine Praxis Neuroframe.
Die Arbeit ist meist unsichtbar, wenn sie gelingt: ein Kalender, der nie doppelt bucht, ein Aufnahmeprozess, der sich selbst weiterleitet, ein Berechtigungsmodell, das ein Sicherheitsteam ohne ein zweites Meeting abnimmt. Was es zu beurteilen lohnt, ist nicht das Feature – es ist die Argumentation darunter und ob sie den Produktivbetrieb überstanden hat. Diese Seite ist also genau der Record davon: jedes System mit seinen Entscheidungen, Vorfällen und Überarbeitungen, geschrieben, um geprüft statt bewundert zu werden.
Wie ich denke
Entscheidungen vor Code. Ich schreibe die RFD und argumentiere den Trade-off, bevor ich baue. Die Argumentation überdauert die Implementierung.
Der langweilige Mechanismus gewinnt. Zwischen einer cleveren Lösung und einer faden, beweisbar korrekten liefere ich die fade aus – sie ergibt auch um 3 Uhr nachts noch Sinn.
Mach das Versagen behebbar, dann veröffentliche es. Nicht alles lässt sich verhindern; alles kann sicher versagen und ein ehrliches Post-mortem bekommen.
Dupliziere nicht den Zustand der Plattform. Eine zweite Quelle der Wahrheit ist eine zweite Sache, die falsch sein kann. Ich entferne Teile, bevor ich welche hinzufüge.
Fertig heißt, jemand anderes kann es betreiben. Dokumentation ist nicht der Papierkram nach der Arbeit – sie ist der Beweis, dass die Arbeit fertig ist.
Wie ich hierhergekommen bin
Die erste Request for Discussion geschrieben. Jedes System seither beginnt als nummerierte, argumentierte RFD, bevor irgendein Code entsteht.
Least-Privilege-domänenweite Delegation über Calendar, Gmail und Drive – so eng gefasst, dass sie die Sicherheitsprüfung eines Kunden besteht, statt sie zu umgehen.
Ein ereignisgesteuerter Job-Runner mit Audit-Trails pro Durchlauf; wiederkehrende menschliche Prozesse wurden beobachtbar und wiederholbar.
Terminplanung auf Google Workspace ohne führende Datenbank. RFD-014 ersetzte Kompensation durch Serialisierung pro Behandler – die Doppelbuchung hörte auf.
Ein Sommerzeit-Vorfall trieb einen v3-Neubau und eine DST-Regressionssuite voran; im selben Jahr ging eine KI-gestützte Aufnahmeschicht in den Produktivbetrieb.
Begann, die Systeme, Entscheidungen und Vorfälle als diesen Operating Record zu veröffentlichen.
Woran ich gerade arbeite
Meist ist etwas auf halbem Weg von privat zu öffentlich: das Entscheidungslog in offene Ansicht zu erweitern, wo die Vertraulichkeit der Kunden es zulässt, und die hier bereits dokumentierten Systeme zu härten. Mit der Zeit wird der Kontaktfluss auf dieser Seite auf derselben Buchungs-Engine laufen, die in ihrem Dossier beschrieben ist – der Record, der sein eigenes Hundefutter frisst.