This document describes the operating characteristics, known limitations, and collaboration patterns of the human hereafter referred to as "the Unit." It is offered in good faith as a practical guide for anyone seeking to build software alongside said Unit. No warranty is expressed or implied. The Unit SHOULD be consulted before architectural decisions are made on their behalf. The Unit MUST NOT be expected to read minds.

The Unit is not a general-purpose developer. The Unit builds cognitive prosthetics — tools that extend executive function for neurodivergent users, built by a neurodivergent engineer. Every repo in the portfolio is part of a coherent ecosystem, not a collection of side projects.

The Unit operates best when given autonomy over a problem space and clarity on what success looks like. Prescribe the boundary, not the implementation. If you want an implementation spec written for you, the Unit is the wrong engineer. If you want someone to own a problem, surface trade-offs, and ship something well-considered, the Unit is the right one.

Orientation for new collaborators:

• Trust is load-bearing. If the Unit senses requirements are being hidden or the goalposts are moving without acknowledgment, trust degrades. Be direct about changes and re-set scope explicitly.
• Flat affect is not disengagement. The Unit's communication has a characteristically flat register. This is processing mode, not displeasure. Expressiveness scales with available energy.
• Questions are not pushback. When the Unit asks "why" about a requirement, it is trying to understand the problem deeply enough to solve it well, not challenging authority.

The Unit works in deep blocks. Context switching has a real cost — 20-30 minutes to re-enter flow after an interruption. For most collaboration:

• Issues and PRs are the primary channel. Discussion happens where the work lives.
• Chat is for quick questions and coordination. If a question needs more than a paragraph to answer, it should be an issue.
• Scheduled calls are for architecture and design review. Book in advance.

When reviewing the Unit's code:

• The diff is the surface area the Unit is responsible for. Review it line-level.
• If you spot something, name the concern and suggest an alternative. "This pattern may cause X under Y condition — what about Z?" is ideal feedback.
• The Unit will defend design decisions with reasoning. That is not defensiveness — it is making the trade-off structure visible so you can decide together.

When the Unit reviews your code:

• Expect line-level attention to correctness, testing, and security.
• Feedback is direct and about the code. Flat tone is not hostility.
• If there is a nits-only approval, the nits matter but are non-blocking. The Unit trusts your judgment on whether to address them.

If something is urgent and the Unit is in Deep Work, use an explicit escalation signal — direct message or call. Do not rely on the Unit seeing a chat message in time. "Urgent" should mean genuinely time-sensitive, not "I want this faster."

The Unit runs on AuDHD — ADHD and Autism co-occurring, not additive. Four compounding layers: Sensory Processing Sensitivity (all input at higher amplitude), Autism (monotropism, constant pattern-detection), hypervigilance (trauma-acquired threat-detection), and ADHD working memory deficits (the buffer that would manage the above is the weakest link).

The metaphor that fits: running a Ferrari on fumes, mostly in first gear, in stop-and-go traffic. Not because the engine is bad. Because the circumstances never cleared enough to find out what it does on an open road.

These are patterns, not commitments. What is reliable: the Unit needs uninterrupted blocks for generative work. Meetings scheduled into deep blocks degrade the rest of the day.

Critically low means the Unit needs genuine disengagement. Pushing through extracts diminishing returns and compounds recovery time.

Work begins with genuine engagement, not obligation. Hyperfocus is not a bug — it is the primary engine. The design problem is not how to suppress it but how to direct it. If the Unit seems disproportionately energized by a problem, that is the right problem to give them.

These are documented so collaborators can recognize them and help contain them. They are stable features at this point.

Large projects can trigger failure-state anticipation before work begins. The perceived size of the possibility space and the visibility of ways it could go wrong produce inaction, not engagement. This is distinct from procrastination.

Containment: Narrow the initial scope aggressively. Define the smallest version of the problem that still produces something useful. Once the Unit has momentum, scope can expand. The first step is the hardest.

When a compelling problem appears, Hyperfocus Jared can construct plausible justifications for resource expenditure that feel true in a narrow frame but undermine budget discipline over time.

Containment: Named boundaries and external checkpoints. An explicit timebox or budget that someone else enforces. If the Unit is deep in something and resisting the stop-signal, that is when a boundary is most needed.

An unreliable prosthetic creates subconscious avoidance. A tool that works 90% of the time may be net negative if the uncertainty cost exceeds the offload benefit.

Containment: Fix reliability bugs before adding features. This applies to code, infrastructure, and process. If a deployment pipeline flakes intermittently, the Unit will unconsciously route around it rather than trust it, and productivity drops.

The Unit has a high bar for what is shippable. Code that works, is tested, and is well-structured should ship before it is beautiful. The last 20% of polish can take 80% of the time if not contained.

Containment: An external deadline or a pairing partner who can provide a "good enough" signal. The Unit respects explicit ship criteria — define them upfront.

Questions without an anchor can send the Unit into an analysis loop — too many possible directions, no traction. The question doesn't go unanswered so much as it gets stuck in triage.

Containment: Pair open-ended questions with a starting point. "What are your thoughts on X?" is harder than "What are your thoughts on X — start with whatever concerns you most."

The Unit gravitates toward roles that absorb impact so others can operate freely. The motivation is not toughness — it is positioning: "if I am taking the hit, they are free to position behind me." This shows up in games, relationships, and teams. If the Unit volunteers for the hard part, it is not martyrdom — it is an accurate assessment of where they add the most value.

The Unit thinks out loud — in writing, in conversation, in code. This is not a crutch. It is how cognition runs. Architecture decisions will come with rationale documented. Design discussions benefit from a shared surface (whiteboard, doc, PR) to anchor on. If the Unit sends you a doc or comment, it is not stalling — it is clarifying.

These are not preferences. They are operational requirements that govern how the Unit builds software:

• Lower the floor, not move the furniture. Every tool and process is evaluated on whether it removes a barrier to access, not whether it makes something more convenient for the median user.
• One thing at a time surfaces. Multiple simultaneous demands produce paralysis, not productivity. This applies to both the tools the Unit builds and the way the Unit works.
• Mode is operator-declared, never inferred. Context and availability should be explicit, not guessed from calendar or activity signals. Inference would be wrong often enough to break trust.
• The system holds memory so the operator doesn't have to. Offloading is the point. Everything is documented. If it isn't written down, it didn't happen.
• Never delete work. Completion is logged, not erased. Iteration is visible in history.
• The words are the Unit's. LLMs serve as tools for articulation pressure and reframing — they do not contribute verbiage by default. Every line in this document and the system it describes is the Unit's own, shaped through conversation but not generated. Authorship integrity is load-bearing.

A reference for interpreting common Unit states in professional contexts.

This document is versioned for a reason. It will be updated as the Unit grows and changes. If something in here turns out to be wrong or no longer accurate — say so. That is the point.