`portal-trainer generate` turns a plain-words business intake into a content repo in three phases, each held to portal's question_lint: needs.yaml (then frozen, so the generator cannot weaken the spec to pass), structure (revised against the lint's findings until green), and wording (personas answered blind, misroutes fed back; a rewrite that breaks structure is reverted). Model output is written to disk only under aggregates.yaml, site.yaml and questions/**.yaml. `portal-trainer answer` is the blind answerer alone. The LLM is an external command, prompt on stdin, text on stdout: engines/ollama.sh (local Ollama), engines/anthropic.sh (API key), engines/mailbox.sh (hand each prompt to an agent or a person). portal-portal/ is the onboarding site as a portal content repo: the front door is the intake interview, records land in `onboardings` (open -> drafted <-> revising -> live | declined), and it passes its own needs spec. runs/uhhm-2026-09-21/ollama: qwen3:8b and granite4.1:8b as blind answerers on the same eight tasks. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01L4jrCgLiKKHAEFuZUJjckH
45 lines
2.0 KiB
YAML
45 lines
2.0 KiB
YAML
# An intake as the owner of a small building contractor would fill it
|
|
# in: plain words, no portal vocabulary. These are the fields the
|
|
# onboarding site asks for.
|
|
business: Nordvik Bygg
|
|
contact: { name: Ingrid Nordvik, email: ingrid@nordvikbygg.example }
|
|
language: en
|
|
|
|
what_we_do: >
|
|
We are twelve people. We survey old buildings, draw up rehabilitation
|
|
plans, handle the permit application, and do the building work with
|
|
our own carpenters plus subcontractors for electrical, plumbing and
|
|
scaffolding.
|
|
|
|
who_comes_to_us: >
|
|
Housing boards and private owners who have a problem with a building
|
|
and want someone to look at it. Owners who already know what they
|
|
want built and need drawings, a permit and a price. Trade firms who
|
|
want to be on our list of subcontractors. Carpenters and apprentices
|
|
asking if we are hiring.
|
|
|
|
what_we_keep_track_of: >
|
|
Enquiries: they come in, we go and look at the building, we send a
|
|
quote, and then we either win it or lose it. Sometimes it is simply
|
|
not for us and we say so straight away.
|
|
Subcontractors: they apply, we check their company registration,
|
|
trade approval and insurance. Often papers are missing and we have to
|
|
ask again. Then they are approved or turned down.
|
|
Job applications: we read them, invite some to an interview, and hire
|
|
or decline.
|
|
Things that go wrong on site: a hazard, a near miss, wrong materials
|
|
delivered. Someone reports it, the safety officer decides what is
|
|
done about it, and closes it when it is fixed.
|
|
|
|
who_is_involved: >
|
|
Two project managers handle enquiries, subcontractors and hiring.
|
|
One safety officer handles everything reported from site.
|
|
The crew, ours and the subcontractors' people, are the ones on site
|
|
who report things. They are on their phones, with gloves on, and
|
|
will not fill in a long form.
|
|
|
|
what_slows_us_down: >
|
|
Enquiries arrive by phone, email and text and get lost. We never know
|
|
which subcontractors have valid papers. Site problems get mentioned
|
|
at lunch and forgotten.
|