Dave
awaiting choice
State · awaiting choice
52 decision records in decisions/ are proposed and none has a selected_by. The loop is at the choice step and the choice is Dave's. This is the protocol position; it says nothing about whether any scheduled automation is running.
Last observed run 2026-07-04 · records/automation-log.yawn
Where it goes
- moving · when Dave chooses on the next question, "One governing record per concept, lenses marked" · decision record
- orienting · if the ranked queue changes before a choice is made
- holding · if the choice is held rather than made
Source · records/yawn.bot-state.yawn at fbd066c
Speed run · 1× · every hour · default · status
What direction does this Yawn serve?
So that Dave stays flexible and agile with as much agency as possible, while the bills are paid and leverage is as high as it can be.
chosen · Dave, 2026-09-12 · recorded on his behalf in core/entity-and-coupling.yawn at fbd066c · reported upstream, not yet ratified in a record he wrote · correct it there
What is a purpose vector?When two records define the same thing (lacuna, the loop, the objective lifecycle, a promotion gate, a read order), does one of them govern, and does it say so?
Candidates
- A
Each concept has exactly one canonical record. A second record that restates it is merged into the first or removed; friendly names and alternate loop phrasings are dropped in favour of the technical one.
- B
Parallel definitions may coexist. No record is required to name another as canonical; readers reconcile drift themselves.
- Crecommended · attributed, no authority
Each concept has one canonical record. Any other record that restates or rephrases it must carry a typed pointer to the canon (same_as, derived_from, supersedes, or projection_of, as core/holarchy.yawn already defines) and must not contradict it. Friendly names and loop rephrasings are allowed only as marked lenses over the canon.
The decision record's options, names and descriptions only, with the attributed recommendation marked; choosing one here is Dave's proposal until he fills choice: in the record. Cost, risk, and proof_needed stay in the record.
The recommendation above is the bot's sealed prediction (2026-09-12, shown beside the candidates, so anchored). Propose or write to score it and check its reason.
Why it matters
core/orientation.yawn already says one model with non-canonical lenses, yet the corpus ships two lacuna definitions, a five-stage and a nine-stage objective lifecycle, and gate definitions that have drifted apart, so a reader cannot tell which binds. Once answered, a bot reading core/ inherits exactly one definition per concept, and a child Yawn that coins its own phrasing knows it must point at the canon rather than become a second one.
What you have put here
Open this question to answer it.
Should every record, loop and receipt get the same depth of proof, memory and indexing, or should the heavy machinery be concentrated on the few that can spend, publish or mutate, and should that choice be written down?
Candidates
- A
Coverage is concentrated. A record, loop or schema gets a runnable proof, a memory root and a full approval contract only when it can spend money, publish, send, or mutate canonical state; every other record declares proof.status: seed-backed or none, and the criterion is written once in agents/yawn.bot.policy.yawn.
- B
Coverage is even. Every automation carries canonical_memory and a ledger, every record carries a proof block, and every receipt records every gate against every axis whether or not it fired.
- Crecommended · attributed, no authority
Coverage is concentrated across records but exhaustive inside a receipt. Which records get heavy machinery follows option A's criterion; but any receipt or migration record that exists to prove something enumerates everything it assessed, including gates that did not fire and paths that were not changed.
The decision record's options, names and descriptions only, with the attributed recommendation marked; choosing one here is Dave's proposal until he fills choice: in the record. Cost, risk, and proof_needed stay in the record.
The recommendation above is the bot's sealed prediction (2026-09-12, shown beside the candidates, so anchored). Propose or write to score it and check its reason.
Why it matters
Today the repo spends its heaviest checks on one unscheduled image loop and on receipt schemas, while 66 of 194 files carry no proof block and only four automations keep memory; nothing says this is deliberate. Once answered, a new bot knows whether it must ship with a memory root, an approval contract and a test before it runs, or only when it can act outside the repo.
What you have put here
Open this question to answer it.
When the repo writes a rule down, must something be able to fail if the rule is broken, or is the written record itself the authority and compliance a matter of reading?
Candidates
- A
Every rule in core/, interface/ and automation/ names a test or validator that fails when it is broken. A rule with no check is labelled proof.status: asserted-unverified in the record that states it and may not be cited as proof by another record. Enum values live in a schema or a test, never only in a trailing comment.
- B
A .yawn record is the authority for what it states. Tests and validators are optional conformance evidence; a rule is honoured by being read, and proof blocks are narrative.
- Crecommended · attributed, no authority
A rule a program could check (a vocabulary, a required field, an authority flag, a path, a hash binding, an ordering) must be enforced by a named test or validator. A rule that needs a human (was the question worth asking, is the move bounded, is this an instrument or a prohibition) is exempt but must be listed under proof.human_review_required, as records/inquiry-aperture-one-question-face.yawn already does. Every proof: block on an active record carries covers: and not_covered: so the boundary between the two is visible.
The decision record's options, names and descriptions only, with the attributed recommendation marked; choosing one here is Dave's proposal until he fills choice: in the record. Cost, risk, and proof_needed stay in the record.
The recommendation above is the bot's sealed prediction (2026-09-12, shown beside the candidates, so anchored). Propose or write to score it and check its reason.
Why it matters
The repo already learned once that a trailing YAML comment is not an enforcement: the epistemics commit blamed exactly that mechanism for the drift it then had to lock with a test, and the same comment-enum pattern still sits on five templates. Once answered, a bot reading core/ knows which rules will stop it (a validator will reject its record) and which are asked of it (a human will review), instead of treating every sentence as equally binding or equally optional.
What you have put here
Open this question to answer it.
When does one concern earn its own .yawn — whenever it has a name or an ID, or only when its proof, owner, status or rollback would differ from its parent's?
Candidates
- A
Every distinct concern (a relationship, a desire, a draft extension, a module, a generator, a move) is its own record, linked from its parent by a typed pointer. Embedding a concern that could stand alone is not allowed.
- B
A record may hold everything about its subject, including drafts, extensions and sub-moves at other statuses. Splitting is the author's discretion and needs no stated criterion.
- Crecommended · attributed, no authority
A concern becomes its own record when its proof condition, owner or authority, lifecycle status or version, or rollback scope differs from its parent's (the five conditions in core/RELATIONSHIP_FIRST_AGENT_ARENA.yawn section 13 plus the merge_counterexample in examples/merge-split-routing.yawn, written once in core/holarchy.yawn structural_change_rule). Having an ID, a message boundary or a viewpoint is never sufficient on its own. Consequences named: objective_holon_extension_0_1 (status working-draft inside a v1 record) becomes its own record linked from core/motivation-and-purpose.yawn; scripts/node.yawn lists generators under a separate generates: key with the purpose line corrected. A turn's plural moves stay embedded because each carries its own authority_ref by design.
The decision record's options, names and descriptions only, with the attributed recommendation marked; choosing one here is Dave's proposal until he fills choice: in the record. Cost, risk, and proof_needed stay in the record.
The recommendation above is the bot's sealed prediction (2026-09-12, shown beside the candidates, so anchored). Propose or write to score it and check its reason.
Why it matters
The repo authors both halves of this: it splits a bot across four files and links rather than merges overlapping records, yet refuses one-Yawn-per-message and one-Agent-per-viewpoint; meanwhile a working-draft extension sits inside a v1 record and a generator sits inside a node defined as checks-only, unremarked. Once answered, a child Yawn deciding whether to fork a relationship, a desire or a draft into its own file applies one written test instead of guessing from precedent.
What you have put here
Open this question to answer it.
When a record leaves a field off, does that mean the field was optional or that the record is incomplete, and should every contract say which fields are which?
Candidates
- A
Every key in a contract's declared shape is required unless the contract lists it under optional:. A record missing a shape key is invalid.
- B
Every key is optional unless the contract lists it under required:. A record carrying only what it knows is complete.
- Crecommended · attributed, no authority
Goal fields are optional; recovery fields are required. A record need not carry a target, a move, or a parent Yawn. It must carry every field that says how it can fail or be undone: proof.status, reversibility, stop_condition, residual_lacuna_refs, unintended_effects, and all four authority flags wherever one appears. Every contract carries a required: list naming these; model-derived classifications (summary, sentiment, severity) are never in it.
The decision record's options, names and descriptions only, with the attributed recommendation marked; choosing one here is Dave's proposal until he fills choice: in the record. Cost, risk, and proof_needed stay in the record.
The recommendation above is the bot's sealed prediction (2026-09-12, shown beside the candidates, so anchored). Propose or write to score it and check its reason.
Why it matters
The written rule makes goals optional (a Yawn needs no target, an Observation needs no Yawn), but nothing says which fields a record must carry, so migrations/node.yawn ships a proof block with no status and the Homebase contract declares two of the four authority flags. A bot reading a record cannot tell silence from permission until this is answered; a child Yawn inherits either a required list or a guess.
What you have put here
Open this question to answer it.
Must a .yawn stay readable and checkable with nothing installed, or is it enough that the record reads with nothing while checking it needs Node and ajv and running it needs Dave's Windows desktop — and is that three-way split written anywhere?
Candidates
- A
The protocol runs on a named stack. Records may name absolute workspace paths, PowerShell scripts and vendor tools; package.json declares engines; the v0_lock entries 'no required parser' and 'no required UI' are struck from core/design-principles.yawn and the yawn-space rule is narrowed to the record text only.
- B
Zero-dependency portability at every layer. Every record reads with nothing; every check runs on any host with Node alone (ajv vendored or dropped, both .ps1 scripts ported to .mjs); no tracked record carries a drive-letter or OneDrive path — workspaces are `workspace_ref:` names resolved from an untracked local file; principals are roles (principal:dave), never a hard-coded address.
- Crecommended · attributed, no authority
Three layers, each written where it binds. (1) Reading: a .yawn record needs nothing installed — the v0 lock stays. (2) Checking: conformance needs the pinned toolchain declared in package.json engines and named in scripts/node.yawn, whose purpose changes from 'dependency-free checks' to 'one pinned toolchain, no runtime authority'; ajv is the one declared dependency. (3) Operating: an automation needs an operator workspace, written as `workspace_ref:` and resolved outside the tree; no tracked record carries a drive-letter path. The two PowerShell scripts are either ported or marked operator-only under layer 3 and excluded from layer 2's promise.
The decision record's options, names and descriptions only, with the attributed recommendation marked; choosing one here is Dave's proposal until he fills choice: in the record. Cost, risk, and proof_needed stay in the record.
The recommendation above is the bot's sealed prediction (2026-09-12, shown beside the candidates, so anchored). Propose or write to score it and check its reason.
Why it matters
The written rule promises a boring portable folder that works with no software, while the only proof that anything holds is a Node 22 test suite with one npm dependency, and the four scheduled automations run PowerShell against Dave's OneDrive desktop paths that appear 32 times across 12 tracked records. Once answered, every child Yawn and bot below Dave inherits an explicit answer to what it may depend on at each layer, instead of copying whichever absolute path or interpreter it finds nearest.
What you have put here
Open this question to answer it.
When a record, template or gate says nothing, is the answer no until someone opens it — and does that rule also cover the values a template ships prefilled, like reversible: true, status: accepted, or a consent list that starts with yes?
Candidates
- A
Nothing is permitted by default. Every field that carries authority meaning (authorized, consent, follow_up_allowed, status, confidence, capability exposure, reversible) ships empty or at its most conservative value in every template and question output block; a permissive value exists only where an author wrote it and can be asked why.
- B
A field is open unless a record closes it. Templates may prefill permissive values; root documents govern by enumerating prohibitions, and anything not prohibited is allowed.
- Crecommended · attributed, no authority
Nothing is permitted by default, EXCEPT reversible, which may ship true because reversibility grants nothing (questions/what-can-i-do-next.yawn boundary: 'Reversibility does not silently grant authorization') — that sentence is copied next to every prefilled reversible. templates/observation.yawn ships status: draft and no confidence; codex-t4o-parser lists unknown first like email-intake; agency-declaration.yawn move.authorized: true is grandfathered by name as the principal's own published act and gains selected_by: principal:dave.
The decision record's options, names and descriptions only, with the attributed recommendation marked; choosing one here is Dave's proposal until he fills choice: in the record. Cost, risk, and proof_needed stay in the record.
The recommendation above is the bot's sealed prediction (2026-09-12, shown beside the candidates, so anchored). Propose or write to score it and check its reason.
Why it matters
The written rule (capability plane zero-exposure, four authority flags false, capture locked first) is deny-by-default, but four templates and one root record quietly ship the opposite, and every record copied from them inherits an authorization nobody gave. Once answered, a bot that copies templates/observation.yawn or interface/move.yawn knows whether the values it inherits are permissions or blanks it must earn.
What you have put here
Open this question to answer it.
Is this public repository a public surface that must carry sanitized summaries only, or a source record that keeps full detail, including local file paths and real family names?
Candidates
- A
The public repository is a public surface under agents/yawn.bot.policy.yawn privacy.public_surfaces. No active .yawn record may carry a local filesystem path, a private link, or personal data about anyone other than the principal. Fuller evidence lives on a private surface and is labelled private.
- B
The repository is the source of record and keeps full fidelity. Local paths, real names and conflicting sources are recorded as they are; compression is a View. Nothing in the repo is redacted.
- Crecommended · attributed, no authority
The repository keeps full fidelity for claims, contradictions and provenance (both sources kept, contradictions survive merge, source detail preserved). Two named classes are redacted everywhere: local filesystem paths, which become a labelled private pointer (private_evidence: labelled, with a reachable public stand-in or none), and personal data about people who are not the principal, which is synthesized as the sibling examples already do unless the principal records consent by name.
The decision record's options, names and descriptions only, with the attributed recommendation marked; choosing one here is Dave's proposal until he fills choice: in the record. Cost, risk, and proof_needed stay in the record.
The recommendation above is the bot's sealed prediction (2026-09-12, shown beside the candidates, so anchored). Propose or write to score it and check its reason.
Why it matters
agents/yawn.bot.policy.yawn says public surfaces carry no private links and sanitized summaries only, yet the active tree holds 15 references to Windows user-profile paths and one example built on the maintainer's real family, so the privacy boundary is stated but not held. Once answered, every bot that writes a ledger or contract into this repo knows whether workspace: may name a local path, and a child Yawn learns whether it inherits a full-fidelity rule or a redaction rule.
What you have put here
Open this question to answer it.
Is 'human-readable first, machine-addressable second' a rule about how a .yawn reads and what leads it, or also about where proof effort and currency go — and if only the first, does any record say so?
Candidates
- A
Machine-addressable first. core/design-principles.yawn reorders its first two principles; the root file may lead with official_runtime and core_loop refs; the human onboarding path is a derived view refreshed when contracts change; normative lists are encoded as YAML an agent can read, with prose as commentary.
- B
Human-readable first for both text and effort. The root file leads with summary; every machine contract that reaches v1 has a human record of equal currency updated in the same change; core/human-use.yawn may not be older than the contracts it explains; boundaries and failure tests are encoded in the same form as invariants so a person and an agent read the same list.
- Crecommended · attributed, no authority
Human-readable first governs the record: a human sentence leads every .yawn (summary before runtime identity), normative lists read the same way for a person and an agent, and a machine block never replaces the human one. carve-out, written down: proof effort goes where effects are — the machine layer may run ahead in validators, schemas and tests, stated as 'proof-bound when promoted' (examples/yawn-spine-dogfood.yawn). One obligation ties the layers: a contract that reaches v1 names the human record that explains it, and that record is not older than the contract.
The decision record's options, names and descriptions only, with the attributed recommendation marked; choosing one here is Dave's proposal until he fills choice: in the record. Cost, risk, and proof_needed stay in the record.
The recommendation above is the bot's sealed prediction (2026-09-12, shown beside the candidates, so anchored). Propose or write to score it and check its reason.
Why it matters
The first principle in core/design-principles.yawn says human-readable first, yet the root file opens with a runtime identity block before its summary, the machine selector is 218 lines against 33 for the human entry path, the contracts reached v1 while the unified human document is not-yet-specified, and the one human onboarding record is two months stale. Once answered, every child Yawn below Dave knows whether its human summary must lead and stay current with its contracts, or whether the contracts may run ahead so long as the record still reads.
What you have put here
Open this question to answer it.
When a record lists things, does the order mean anything, and if only sometimes, how does a reader or a bot know which lists are ranked?
Candidates
- A
List order is rank. The first entry of any list is the default or highest priority unless the record says otherwise.
- B
List order carries no meaning. Only a key named priority, precedence, order, tie_break or ranked is ordered; every other list is a set and may be sorted freely.
- Crecommended · attributed, no authority
List order carries no meaning unless the key is named for rank (priority, precedence, order, tie_break, ranked) or the list carries ordered: true with a one-line reason. The validate chain in package.json and the automation morning schedule are declared ordered with reasons; all other lists are sets.
The decision record's options, names and descriptions only, with the attributed recommendation marked; choosing one here is Dave's proposal until he fills choice: in the record. Cost, risk, and proof_needed stay in the record.
The recommendation above is the bot's sealed prediction (2026-09-12, shown beside the candidates, so anchored). Propose or write to score it and check its reason.
Why it matters
The two written statements say order is not a ladder (scope lenses are locations; questions may be visited in any order), while thirteen unlabelled lists put attain first among target modes, local first among lanes, confused first among sentiments, and the validate chain runs in a fixed order nobody calls fixed. A bot that takes the first item as the default inherits a priority nobody stated; a bot that ignores order in the tie_break list breaks a test.
What you have put here
Open this question to answer it.
May a record be marked active or accepted, or be cited as another record's proof, before its own evidence exists — so long as it is labelled — or must the proof land first?
Candidates
- A
A record may ship, run, be promoted or be cited as soon as its proof status is labelled; evidence arrives later and the label is updated when it does. proof.status: not_started is a valid state for an active record.
- B
Nothing is promoted to active, accepted or v1, cited under proof.source, published, or written to durable memory until its proof condition is met. Working papers wait for review; automations wait for their governing agent contract to leave seed status.
- Crecommended · attributed, no authority
Provisional action is allowed when labelled (publish a paper marked not-peer-reviewed, run an automation marked active-seed, ship an example with proof not_started). Three things wait for proof: promotion of status to accepted, v1 or official; citation under proof.source (a status: proposed or draft record may be cited under proposal_refs: or source_refs:, never under proof.source); and durable memory update. Written once in core/proof-and-boundary.yawn transition_boundary.
The decision record's options, names and descriptions only, with the attributed recommendation marked; choosing one here is Dave's proposal until he fills choice: in the record. Cost, risk, and proof_needed stay in the record.
The recommendation above is the bot's sealed prediction (2026-09-12, shown beside the candidates, so anchored). Propose or write to score it and check its reason.
Why it matters
The written rules say durable memory waits for authority and proof and legacy claims stay historical until restated and proved, yet three nodes cite a status: proposed migration as proof.source, a pattern ledger entry reads accepted with proof 'pending', and eight automations run active under seed-status agent contracts. Once answered, a bot knows whether 'active' on its own contract is a lifecycle fact (it runs) or a claim it must have earned, and whether it may point at a proposal and call it proof.
What you have put here
Open this question to answer it.
Should there be one shared set of key names for what an agent may and may not do, for where a record sits in the loop, and for what a colour means, or may each record coin its own?
Candidates
- A
Each record may name its permit, deny, boundary, loop-position and colour-role keys as it sees fit. The shared-vocabulary rules in core/movement-loop.yawn and interface/yawn-brand-v1.yawn apply only inside their own files.
- B
One shared field vocabulary governs every .yawn record. The permit key, the deny key, the boundary section name, the loop-position key and the colour role names are each fixed in one named record, and every record in the corpus uses those spellings.
- Crecommended · attributed, no authority
Keys a bot reads to decide what it may do or how to render are fixed in one shared vocabulary: the permit key, the deny key, the loop-position key, the colour role names, and the canonical operator. Prose section names (invariants, stable_claims, lock) stay free. The shared set is listed by name in one record.
The decision record's options, names and descriptions only, with the attributed recommendation marked; choosing one here is Dave's proposal until he fills choice: in the record. Cost, risk, and proof_needed stay in the record.
The recommendation above is the bot's sealed prediction (2026-09-12, shown beside the candidates, so anchored). Propose or write to score it and check its reason.
Why it matters
Every authored rule on this axis says one grammar (six fixed loop relations, one relational grammar, exact palette values, one canonical operator), yet across 22 agent and automation files the permit key appears six ways and the deny key seven, and the chrome contract hardcodes hexes the brand contract told it to reference. Once answered, a bot that checks its own boundary can read one key instead of guessing among may/allowed/agent_may, and a child Yawn inherits a vocabulary rather than a naming habit.
What you have put here
Open this question to answer it.
What if we can control our own reality in finer programming detail?
Why it matters
I am exploring the image of programs that wake up. What could I influence through attention, choices, tools, and relationships? What would distinguish that from literally programming external reality? The programming premise remains an open hypothesis.
What you have put here
Open this question to answer it.
What am I to be?
Settled 2026-09-12 · recalled from the record, not reopened
Steward of yawn.bot. So that Dave stays flexible and agile with as much agency as possible, while the bills are paid and leverage is as high as it can be.
Why is this question here?
Answered questions drop below the open ones; the top slot belongs to the next highest-leverage decision.
When the role question resurfaces, answer from this record first — "last time we checked, what you are to be is steward of yawn.bot, so that…" — and do not reopen it unless Dave corrects the answer. It has dropped from the top slot.
Recorded in core/entity-and-coupling.yawn; the working account of who Dave is stays below as support.
How is this answer supported?
working model · revisable · I want more choice in how I live, more agency, and more meaning. What I understand now is a working account, open to something I have not encountered or been taught yet.
What is my current account based on?
More possibilities to choose from
I would like reliable options, even age-reversal pills, if they could give me more choice in my life.
aspiration · A wish, with reliability still to be established.
Assumptions I may not see
The fishbowl is my metaphor for assumptions that are hard to notice from inside my own experience.
metaphor · A prompt to check my assumptions against experience and other perspectives.
A model can be corrected
My models of myself and my relationships can miss something. I want to see whose interpretation I am reading, what it came from, and what would change it.
working interpretation · An interpretation is not the person it concerns. Other people keep their own voice and boundaries.
The first person refers to Dave. This is a selected public account, not the full source text, a new Dave identity, or a claim about the executing AI. The headline asks about the Dave Yawn as a revisable account, following source:dave-notifications-inquiry-release-2026-09-09.
Source and revisionRole: core/entity-and-coupling.yawn at fbd066c
What is this to be?
Dave’s guiding inquiry, answered so far by the values below · Time-jump is the lead initiative
I ask this of the Dave Yawn: what should this evolving account make possible? Time-jump remains my lead initiative. Say what IS, notice the pattern, choose one different move, and check what changes.
Why is this question here?
Below the open questions because what it carries is a judgment: the values, beliefs, and proof Dave stated on 2026-09-09 for deciding what to do. The inquiry itself stays open.
Its position is not a probability or a measure of truth; the source is public/dave/model.yawn.
How is this answer supported?
How do I decide what to do?
- Coordinate before interpretation
- Show where a signal may belong before explaining the whole graph.
- Inference stays visible
- Expose inherited context, confidence, evidence, alternatives, and uncertainty.
- Correction is the training signal
- Record what fit, what failed, and the coordinate the person selected.
- Proof changes future behavior
- A rule graduates only after accepted receipts survive replay.
- Capability is not authority
- A model may propose movement; relationships and explicit grants govern effects.
- Values I keep
- Agency over dependence. Family time over performative busyness. Proof over persuasive claims.
- Beliefs I work from
- Cognition can be made visible. AI should expose its inference. Correction can compound into better behavior.
- Habits you can observe
- Externalize a felt gap into dialogue. Name the missing architecture. Iterate until the interface carries the meaning.
- Proof I require
- The behavior works outside the explanation. A receipt names who checked what. The next run changes for an inspectable reason.
What would change this account?
Source and correction
Take this account into a Yawn to discuss a correction. That keeps a proposal for review; it does not automatically change this public account.
Why is this question here?
Last on purpose: the source, hashes, and correction path for everything above.
A correction proposal followed by a reviewed source edit is the only way this account changes; nothing on this page edits it.
How is this answer supported?
This edited account only. Private sources, conversations, relationship records, and other people's accounts are excluded.
Continue captures this receipt in this tab’s Yawn flow. Visitors can keep device recovery; Dave’s signed-in owner view can save privately. Review existing meaning and placement there. This does not publish the receipt or adopt the model as true.
Inspect attribution and source hashes
- Subject and source author
- user:dave
- Edited projection
- agent:openai:codex
- Source reference
- source:dave-face-humility-provisions-2026-09-09
- Captured from visible user text
- 2026-09-09T01:53:14Z
- Original text SHA-256 · raw text kept private
- 88b411c95b18b570a8cd8007eb7869e9e9c2922f8eb31d22c0eac3d0f15eb118
- This public model SHA-256
- ce562c55ccd679491991ac162ce3f0d2c44a9e335068c4ebbbfa57d1b16273b4
- Version
- 2026-09-13.4
- Bot state and queue
- records/yawn.bot-state · scripts/render-bot-state.mjs · pinned at fbd066cf1920d9f99546aa54ea70050d46ab6c6e
- Last observed bot run
- 2026-07-04 · records/automation-log.yawn · observed
- Additional source reference
- source:dave-is-and-reality-questions-2026-09-09
- Source author
- user:dave
- Captured from visible user text
- 2026-09-09T03:00:34.110Z
- Original text SHA-256 · raw text kept private
- b3b559f1510cab4c2d64aa2df603053bf04abd641dc7b99cd30022f52671851b
- Additional source reference
- source:dave-notifications-inquiry-release-2026-09-09
- Source author
- user:dave
- Captured from visible user text
- 2026-09-09T03:15:41.781Z
- Original text SHA-256 · raw text kept private
- 2ced17f6bbad91142d28fb3bb956bdf826a438a06223aebccdd2fda848212869
- Additional source reference
- source:dave-ai-talk-in-the-park-speech-2026-09-13
- Source author
- user:dave
- Captured from visible user text
- 2026-09-13T04:09:16Z
- Original text SHA-256 · raw text kept private
- 10308f9d6d7f902fee2662052a738da4041ecbfce4e92f265d9d8f483dba3f20
