Separate what a worker does from what a company needs filled

Owliver could offer neither create. The Create Position flow worked and no chip
anywhere suggested it, because the chip row is entirely the backend's static
catalogue and no intent in it wrote anything. The gap was never in the
frontend's trigger matching — every phrasing already routed.

`employee_roles` is the supply side of `job_postings`. A posting is what the
ORGANIZATION needs filled; this is what a WORKER says they do. They share a
vocabulary and almost nothing else: "3 years" on a posting is a minimum an
applicant must clear, and the same words here are what the person has. There is
deliberately no foreign key between them — supply and demand already meet
through `job_applications`, which carries the funnel, the interview and the
outcome, and a second weaker link would disagree with it the first time
somebody withdrew.

NO NEW COMPANY ENTITY, AND THAT IS THE LOAD-BEARING DECISION. "Create a company
position" reads like it needs a client record. `organizations` is the TENANT —
absent from the resource table, absent from the policy map, written only by the
seeder — so creating a row there from a chat flow would provision a new tenant,
and the position would carry an org_id the operator's session cannot see. The
operator could never view the record they just created. That breaks I5 and I1
to add a feature nobody asked for. The client stays free text on the posting,
per blueprint decision D2, and the flow simply offers the clients this
organization already staffs for as chips. No schema change, no endpoint change.

Create is operators-only, and that is an I1 decision rather than a deferral.
The worker is named explicitly on the row and is deliberately NOT derived from
the session, because an operator recording a role on somebody's behalf is the
whole point of the flow. Granting talent the same Create would let a talent
caller write a role under any worker_email in the tenant — the attribution hole
Phase 3D closed elsewhere. Talent reads its own via a ScopeEmail predicate,
which is in place now so the grant is one line when a talent console exists.

`created_by` is in gen_resources.py's SERVER_OWNED as well as the policy's
Derived list. Both are required and the pairing is easy to miss: Derived fills
the column from the session, SERVER_OWNED is what makes the descriptor ReadOnly
so a request body cannot set it in the first place. Without it,
TestDerivedColumnsAreReadOnlyOrTalentScoped fails — verified by mutation, not
by reading.

The two catalogue intents carry PHRASE terms only. A bare "position" or "role"
term scores 10, the same as every reading on that page, and wins the tie on
declaration order — so a create chip would have arrived by evicting
`positions-attention` from the exact ordered result TestPositionsSuggestions
asserts. An offer to create something must not displace the reading a person
actually asked for. Neither declares a Subject, on the precedent of
`position-spec-steps`: a Subject would let the bare query "summarize" match
through matchShape and survive filterOnTopic. Neither declares a Signal, so an
empty composer still reports what the organization needs rather than proposing
paperwork.

Chip text is the coupling with nothing else holding it together: no page
context declares `capabilities`, so every server suggestion dispatches as its
own TEXT and is answered by whichever skill's trigger that text matches. A
renamed chip would open nothing, silently. Asserted on the frontend side.

The down migration drops `employee_role_status` and keeps `english_level`,
which is shared with job_postings.english_required and
job_applications.english_level. Rolled back and re-applied against the
database to prove it, not asserted.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PJvibeSc1JYXjatankqM1g

go-api/internal/owliver/suggest_test.go

@@ -110,6 +110,85 @@ func TestPositionsSuggestions(t *testing.T) {
 
 /* ── Candidates ─────────────────────────────────────────────────────────── */
 
+// Creating a record is offered on the words people actually type, and the two
+// creates are told apart by the words that distinguish them.
+//
+// This is the half of the feature that was missing entirely: the flow behind
+// "create a position" worked, and no chip anywhere offered it. Every phrasing
+// below reached the frontend's trigger matcher already — the gap was that the
+// panel never suggested any of them.
+func TestCreateIntentsAreOffered(t *testing.T) {
+	for _, c := range []struct {
+		query string
+		want  string
+	}{
+		{"create position", "create-company-position"},
+		{"create positions", "create-company-position"},
+		{"create a position", "create-company-position"},
+		{"create new position", "create-company-position"},
+		{"new position", "create-company-position"},
+		{"post a job", "create-company-position"},
+		{"create a company position", "create-company-position"},
+
+		{"create an employee role", "create-employee-role"},
+		{"create employee role", "create-employee-role"},
+		{"add an employee role", "create-employee-role"},
+		{"new employee role", "create-employee-role"},
+		{"create worker role", "create-employee-role"},
+	} {
+		t.Run(c.query, func(t *testing.T) {
+			got := intents(ask("positions", c.query))
+			if len(got) == 0 || got[0] != c.want {
+				t.Fatalf("query %q: got %v, want %s first", c.query, got, c.want)
+			}
+		})
+	}
+
+	// And the supply-side create is on the page that reads the supply.
+	if got := intents(ask("talent-pool", "create an employee role")); len(got) == 0 || got[0] != "create-employee-role" {
+		t.Errorf("talent-pool: got %v, want create-employee-role first", got)
+	}
+}
+
+// A create chip is never proposed to somebody who cannot create.
+//
+// The gate is the policy table, not a role list repeated here: employee-roles
+// and job-postings both grant Create to operators only, so talent is offered
+// neither — while still being offered their own readings elsewhere, which
+// TestTalentIsStillOfferedTheirOwnReadings holds.
+func TestTalentIsNeverOfferedACreate(t *testing.T) {
+	for _, page := range []string{"positions", "talent-pool"} {
+		for _, query := range []string{
+			"create position", "create a position", "new position", "post a job",
+			"create an employee role", "add an employee role", "employee role",
+		} {
+			for _, s := range Suggest(page, query, domain.RoleTalent) {
+				if strings.HasPrefix(s.Intent, "create-") {
+					t.Errorf("talent was offered %q on %q for %q", s.Intent, page, query)
+				}
+			}
+		}
+	}
+}
+
+// The create chips arrive without evicting a reading.
+//
+// Their terms are phrases only for exactly this reason. A bare "position" term
+// would score 10 — the same as every reading on the page — and win the tie on
+// declaration order, silently pushing `positions-attention` out of the three.
+// The reading a person asked for must not be displaced by an offer to create
+// something, so this pins the page's own noun to the page's own answers.
+func TestCreateIntentsDoNotDisplaceReadings(t *testing.T) {
+	for _, query := range []string{"position", "positions", "role", "roles", "draft"} {
+		for _, s := range Suggest("positions", query, domain.RoleAdmin) {
+			if strings.HasPrefix(s.Intent, "create-") {
+				t.Errorf("%q offered %q; a bare page noun must answer with readings",
+					query, s.Intent)
+			}
+		}
+	}
+}
+
 func TestCandidatesSuggestions(t *testing.T) {
 	cases := []struct {
 		name  string
@@ -606,6 +685,14 @@ func TestIntentIDsAreFrontendCapabilities(t *testing.T) {
 		// POSITIONS_CAPABILITIES
 		"position-drafts", "position-strength", "positions-attention", "hiring-priority",
 		"candidates-waiting",
+		// The two conversational writes. Not manifest ids: no context declares
+		// `capabilities`, so every server chip dispatches as its own TEXT and is
+		// answered by the skill whose trigger that text matches. They are listed
+		// here because this test is the bijection that keeps a suggestion the
+		// panel cannot run out of the catalogue, and the coupling that makes
+		// these runnable — chip text to skill trigger — is asserted by
+		// `npm test` on the frontend side.
+		"create-company-position", "create-employee-role",
 		// CANDIDATE_LIST_CAPABILITIES
 		"candidates-attention", "top-candidates", "interview-ready", "screening-gaps",
 		"pipeline-summary", "candidate-risk",