/.well-known/caldav answered 307 to https://<domain>/dav/cal, and that
path was portal's catch-all - so a client that did the discovery
correctly followed it into an HTML page. Stalwart builds the Location
from the forwarded host rather than the Host this route rewrites, so
rather than fight that, /dav/* is served here too and the client stays
on one origin for the whole exchange.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015GeH3y8fwTaTudaD88P57o
Portal v0.6.21 serves this repo's .well-known/ at the root of the site,
so security.txt is a file in this repo rather than something only a
reverse proxy could place. A path that is not here answers 404 now,
instead of the app shell answering 200 with HTML.
Caddy also hands /.well-known/caldav and /.well-known/carddav to
Stalwart, which answers each with a 307 to the collection. RFC 6764 has
a client look for these on the domain its address is in - and iOS uses
them, which matters because Apple Mail ignores both autoconfig and
Autodiscover for IMAP accounts and discovers nothing else by itself.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015GeH3y8fwTaTudaD88P57o
Thunderbird asks <domain>/.well-known/autoconfig, Outlook POSTs to
<domain>/Autodiscover, and both fell into portal's catch-all, which
answers 200 with an HTML page - so a client got markup where it expected
XML and went back to guessing.
Both prefixes now go to Stalwart, which already generates the answers,
templated on the address asked about. No static copy to drift out of
date and no hostname of their own to certify. Host is rewritten to the
name Stalwart has always answered for, and all three spellings of
/Autodiscover are matched because Outlook is not consistent about it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015GeH3y8fwTaTudaD88P57o
/einer is four frontiers and nothing else: the gap between berry and
heartwood chemistry, the gap between inhibition on agar and durability
in wood, the delivery problem that a bio-based impregnation chemistry
might already solve, and whether extractive-driven durability can be
moved between species at all.
Context cards only - no form, no bucket, nothing asked for.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015GeH3y8fwTaTudaD88P57o
:has(a[href^="/auth/login"]) only ever matched the signed-out nav, so
an owner still had a name and a sign-out beside the wordmark. The
header carries the wordmark and nothing else now.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015GeH3y8fwTaTudaD88P57o
/einer states what is known about juniper heartwood extractives — the
sesquiterpenes that carry the scent are the ones that inhibit decay
fungi — and what is not, then takes the two things the project needs:
people following along, and people with wood, equipment or lab time.
Both land in one bucket, worked from /review, because at this stage
they are the same conversation.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015GeH3y8fwTaTudaD88P57o
uhhm.no is read and answered without an account, so the invitation to
sign in has no audience. Portal's header nav keeps it next to the
wordmark on every page; a skin hides it, as on redoal.com.
The rule only takes the link in: signed in, the nav still carries the
name and the way out, and the gate on /review still offers its own way
in. First custom.css here, wired through site.yaml's stylesheet key.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015GeH3y8fwTaTudaD88P57o
Attachments both ways, rate limiting, sessions that survive a deploy,
and an upload route that asks the policy like every other way in.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Four releases on from v0.3.36: maps and `place:`, a reply to a case
mail becoming a note on its record, and the access policy's newer
rules. iris moves with it, since it is the lint for exactly this
portal.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
A host reboot on 2026-08-30 left the instance down: deploys only ever
started it. enable is best-effort until the host's polkit rule grants
manage-unit-files to deploy-runner.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Desk/receipt titles become questions (What's been proposed? / What
happens to your proposal? / What came in? / Which proposal is this?),
Where to send it and Record a prospect explain why before the field,
lucide icons on input-bearing features, README's alternatives rule
reworded (draw people in with a real path, not necessarily a slogan)
and its stale /develop-proposal + followup references fixed.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
develop/ holds the whole proposal flow (index = owners desk,
proposal = public form, proposed = chain-gated receipt) with relative
actions; review/ gains _section.yaml (one owners gate for the
directory) and a [record].yaml dynamic page - /review/<chain-hash>
shows a single proposal. Top-level files drop their now-derived id:
and fossil route: fields. URLs /develop-proposal and /proposed become
/develop/proposal and /develop/proposed (no automation references
them - n8n filters checked).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
A private starred repo used to link visitors straight to a 404. The
link now uses the repo's Website setting when set, falls back to the
repo url only for public repos, and renders private repos without a
website as unlinked cards. Also: Gitea serializes the star count as
stars_count, not GitHub's stargazers_count - the stars chip had been
silently null and dropped.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
proposed_yaml binds to the file select: the selected file's content
fetches through Gitea's contents API (base64-decoded by the jq
filter) and lands in the editor. On-site contributions no longer
start from a blank box.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
A linked card straight from Gitea's repo info - proposers can read
what exists before proposing against it.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
target_path becomes a select whose options are the live listing of
questions/ from Gitea's contents API (the engine's existing
select-from-resource mechanism - no code change), with a free path
field kept for proposals that create a new file. No more hand-typed,
typo-able paths for existing pages.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The automation fences commits to questions/*.yaml and aggregates.yaml;
the page and README now say so, instead of promising "any file" and
silently failing after approval.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
It was a worked example of the empathic pattern, not a feature: every
alternative should be empathic, informative, and helpful - information
that gives an answer, not necessarily a path to choose. The pattern
stays (voice rules, README); the investor pages, aggregate, review
alternative, and front-page gateway go. The investors KV bucket and
its test records linger in NATS unreferenced - purge at leisure.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The title is the only question; alternatives are bold statements
argued against each other; explain why input is needed, then hand
over the field; never assume the visitor's role - give the concern
its own page and let the question nav surface it.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- The page title is the only question anywhere; alternative and
feature names are now statements in our voice. Where we need input
we say why (the reply is personal, software lands somewhere, a
proposal is a stance), then hand over the field.
- The opening question's alternatives become the statements we'd like
visitors to get behind: "Good software begins with a clear
argument", "Attention is earned", "Capital needs reasons", "Work
happens through dialogue, not tickets".
- followup: true on the five post-submission pages keeps them out of
the question nav until the visitor actually carries a chain.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
"I want to invest" on the front page presumed the visitor's intent.
/invest now asks it from their side - "How do we invest in uhhm?" -
and speaks to what a capital manager is actually accountable for:
reasons. The front page keeps only a light gateway; the question nav
surfaces /invest (like every other qualifying question) from anywhere,
so no concern depends on front-page space.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Replaces the long-stale schema notes (pre-aggregates, pre-resources,
pre-proposal-loop) with what the repo actually is now: declare a state
graph, give it a way in (submission), a way through (review
transitions), let automations react, and change the system through
itself.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
It existed to prove the round-trip (proposed -> approved -> PR ->
lint -> merge -> live) and it did. Its job is done.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
A development-proposal PR previously got no check at all (the workflow
only fired on push to main) - so branch protection's required status
check, the thing that makes the automation's merge_when_checks_succeed
an actual lint gate, had nothing to require. Lint now runs on both
events; the content-reload NATS publish stays push-only.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- applicants grows past the one decision: invited -> active (onboarded)
-> departed, one continuous graph per person.
- investors: open -> in_dialogue -> committed -> divested, with decline
edges; submission via a new "I want to invest" alternative on /.
- organizations (prospect -> client -> past_client) finally gets pages:
a review listing with its transitions and a record-a-prospect form.
- development_proposals: the question architecture dogfooding its own
development - /develop-proposal takes proposals from anyone (human
today, an LLM later through the same public form), /develop lets an
owner approve or reject, and approval hands off to the automation
that opens the PR (see infrastructure's development-commit workflow).
The repo's own lint CI gates the merge, same as any human commit.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Confirmed it renders correctly (icon + accent border, banner image) -
reverting since which features/alternatives actually get these is an
editorial choice, not mine to make.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
