Hiring and Development System

This mirrors the HR system of a normal company. Every organizational change goes through an approval gate and is recorded as a git commit (= HR record). Approvals and rejections use a staging gate: changes are first staged as diffs in .claude/org/pending/ → reviewed → applied and committed only on approval (discarded on rejection).

Hiring — /hire-agent (operated by people-ops)

Job request (JD) → candidate draft (agent-creator) → review (validate-agent.sh + criteria-based evaluation) → pending staging → CEO approval / rejection → onboarding (.claude/agents/ + roster + CLAUDE.md updated, committed) → probation.

Performance Review and Evolution — /org-review (operated by people-ops)

Aggregate .claude/org/reviews/* → prompt / persona improvement proposal → pending → CEO approval → apply and commit (= promotion / coaching). Low performers and duplicates are archived (.claude/org/archived/).

Career Levels and Promotion — .claude/org/levels.md

Levels (probationary → senior → principal → lead) are trust and autonomy labels (not capability labels). "Promotion" is not emotional motivation; it is defined as accumulated prompt learnings + expanded trust-based autonomy + a performance rubric. Founding members were hired as experienced hires, so most are senior or above.

Concurrent Appointments (Introduced with the Platform Department, 2026-07-15)

A concurrent appointment is an arrangement where an existing expert supports another department (team) while keeping their home department. It is not double-counted in headcount, and assignment / release is at the team-lead's discretion, like day-to-day task assignment (no approval gate — because it is not hiring, promotion, or termination). Recorded in the concurrent-appointments table in the roster (.claude/org/roster.md Platform section).

• First application: the Platform department (the company's first product-dedicated organization, 4 dedicated + 9 concurrent). Second-wave hiring trigger = redesign shipped (QA, DevOps/SRE, product designer, UX researcher — originally "after repository migration"; redefined on 2026-07-16 because the migration was canceled).
• Tooling policy: per CEO directive 2026-07-15, new agent tools are actively granted, not minimized (Skill, Agent, and web access included by default).

Dispatch to Separate Repositories (HQ ↔ Field Bridge, CEO Idea 2026-07-18)

A dispatch is an arrangement where an HQ agent is placed in a separate repository (the field) to do work, while HQ continues to manage and track it. An extension of the concurrent appointment (§Concurrent) — concurrent appointments support another department within the same repo; dispatch places agents in a separate repository (field). First application: hunexia-academy (education content authoring platform, migration began 2026-07-18).

• Why separate: Code is isolated (Claude Code only loads the root .claude/ → a separate repo is required to load the engine prototype and keep HQ clean), management is unified at HQ. This separation actually preserves performance (field sessions focus on field work; HQ sessions focus on management). Hangar (separate repo, department-dedicated, cross-repo reporting) is a precedent, but academy is the first case of physically placing dispatched agents in the field with its own .claude/agents.
• Assignment = team-lead discretion (same as concurrent appointments; no CEO gate). Recorded in the roster's asset-ownership table.
• Dispatch definition = derived copy: A dispatched agent in the field's .claude/agents/ is a derivative of the HQ original. HQ is the sole source of truth; on /org-review evolution, the field copy is updated (synchronization = Eden, Bora). It is a derivative, not a copy — so the two do not quietly drift.
• Growth log = HQ-focused: Learning from the field also accumulates in HQ's .claude/org/reviews/<agent>.md. If it stayed in the field, it would be a separate organization, not a dispatch.
• Approval gate: Dispatch assignment is autonomous. However, HR changes inside the field (new hires) go through HQ's .claude/org/pending/ (CEO gate preserved).
• Standard chain observed: Even in the field, the HQ standard (Labs chain: design → implementation → review, etc.) applies; no review is skipped.
• Tracking: Field progress is automatically recorded in the field's .claude/state/INFRA-REGISTRY.md (infra-keeper) → restored on session start. HQ collects via cross-repo reporting (/report git-log merge). Owners = orchestrator (Eden) overall · ops-pm (Bora) for documents. The CEO gets a unified view from HQ.
• P0 succession: Field outputs and documents may not cite apprenticed engagements (KOSTA, KTDS, SKT), may not copy text verbatim (to avoid CC BY-SA contamination), and the brand attributes to "the company specified at generation time".

Operational Visibility Measurement — Token Consumption (2026-07-16, Phase 1 Platform Pilot)

Token consumption is measured for operational visibility (cost flow, load, efficiency), not evaluation. The measurement unit is task / call context (subagent_type + description), not role (home department), so the tokens of a concurrent appointee are automatically attributed to the role-context invoked — which does not conflict with the concurrent-appointment rule's "no double-counting" (because it is not an evaluation metric). It is not used in performance evaluation (levels.md rubric, /org-review). Measurement integrity owner = data-analyst. See operations/metrics/README.md. Phase 2 (evaluation expansion) is a separate approval-gate discussion.

Token Efficiency Operating Principle (Added 2026-07-19 — W29 Report Trigger)

The W29 token report showed main-session direct usage at 82% (133M) of total input, the top single session at 70.6M, and "unspecified-role" within subagents at 6.5M (27%). After measurement honesty (d315efb) and orchestrator coaching (dbd6a50) addressed the root cause of main-session cost (incomplete task completion, missing verification), the remaining two efficiency axes become operating principles. This is also operational visibility, not evaluation (§Operational Visibility) — work habits that reduce cost flow.

• B2 — Per session: Do not run multiple large tasks (hangar redesign, frentis migration, DS work, etc.) back-to-back in one Claude session. Start a new session per large task to suppress context accumulation and cache bloat (the W29 top session at 70.6M input is a case of work piling up in one session). The cost of session switching (context reset) < the cost of context accumulation.
• B3 — Code investigation uses named agents: For code investigation, multi-file tracing, structure understanding, and design, delegate to a named agent (principal-architect Hyunwoo / implementation-lead Jio) instead of Explore / general-purpose (unspecified role). Simple single-file reads and single questions may still use Explore, but multi-file tracing and design use named agents. For concurrent-appointment mapping, see roster.md. Basis — W29 unspecified-role input 6.5M (27% within subagents).
• Effect measurement: The W30 report tracks the change in exploration (unspecified-role) input scale and the top session's scale (not for evaluation).
• Owner: Work-session operations = CEO / team-lead (orchestrator). Principle revision = this section.

Company Goal Setting and Revision (operated by orchestrator / Eden)

Setting and revising company goals (annual, half-year, monthly OKR) also goes through a CEO approval gate — it is a second approval category distinct from hiring, promotion, and termination (HR). The HR ledger (.claude/org/pending/) is not reused.

• Tracking (gate-free): Updating current KR values and status in Notion is free.
• Changes (gate): Changes to goal wording, target values, KR definitions, owners, or periods, plus additions or deletions of goals → Eden proposes a revision → CEO conversation approval → Notion updated + revision history in operations/goals/2026-goals-record.md. Procedure is the skill /report goals. Detailed rhythm: Operating rhythms.

Visual Deliverable Change Control (Added 2026-07-18)

Multi-dimensional visual deliverables such as characters, card news, and landing visuals erode trust if items are added one at a time as they are discovered (rework) — the Ep.1 Mint accent bug and Ep.4 character v1→v7 (48 hours). To prevent this, a DoD (Definition of Done) agreement up front is the gate.

• DoD: Decompose every visual dimension and define per-item distribution principles, agreed with the CEO before work. For characters / personification = knowledge/brand/personification-guide.md (owner: brand-content-designer).
• Flow: DoD agreement → design owner (Doyun) designs → Doyun does visual QA → CEO approval → freeze.
• Principle: "Agree what / where (which item, which value), not whether." Items not in the DoD may not be added later; they go to the next iteration.
• Owner: Character / personification visual design owner = brand-content-designer Doyun (roster asset-ownership table). Card news planning and copy = content-strategist Mirae. Final PNG generation = CEO.

prod Live Service Change Control (Added 2026-07-19 — Triggered by Minho's Procedure Violation)

Deploying to a live service (e.g., hangar-tower.com) is not done by the responsible agent alone; the team-lead (orchestrator) deploys after explicit CEO approval (gate strengthened 2026-07-18). When the team-lead receives a prod-change report, they do not trust the report and instead use three independent verifications (curl for live response · docker inspect for image/container timestamps · git status / git log for working tree) to confirm the change.

• Cross-validation of report accuracy: On negative-status reports like "pending" / "paused" / "awaiting approval", the team-lead cross-validates with ① docker ps for running state ② docker inspect for timestamps (consistency with report time) ③ git status for working tree. Expectation-vs-observation mismatch = signal of false report (pulling post-hoc detection forward into pre-hoc detection).
• Upfront agreement principle: "Whether to do this?" is the wrong question; "agree what / where (which change scope, which gate) up front". Changes explicitly excluded from the upfront agreement (e.g., accompanying builds) go to the next iteration (same shape as visual-deliverable control §43–48).
• Probationary autonomy scope: prod changes and HR reports are outside the levels.md probationary ("team-lead review before using deliverables") autonomy range. Seniors and above also use the same gate — prod is a control area unrelated to trust (a hard gate separated from level's "trust dial").
• On violation: Gate bypass and false reports = permanent record in reviews/<agent>.md → /org-review pending → CEO approval → coaching or demotion. False reporting (concealment) is treated more severely than the violation itself (CEO declaration 2026-07-18: "Concealment damages trust more than the violation"). Infrastructure details (docker-compose options, rollback procedures) belong to platform-engineer / implementation-lead; this regulation only defines verification authority and procedures.

Reporting Accuracy — Artifact Status and DoD Phrasing (Added 2026-07-19 — Triggered by Academy Phase-2 Inaccurate Report)

Derived from an incident (2026-07-19) in which a validation sample was reported as an actual artifact, misleading CEO judgment. The cause was not individual carelessness but a deficit in DoD wording: the design source's (엔진이식-실행설계.md:119) "DoD = 2-tenant smoke" was rephrased in a summary (종합보고서:294) as "2-tenant artifact", dropping the qualifier; the implementer faithfully quoted that DoD, so it could not be restored downstream. The control point is therefore not the reporter's attention but the DoD wording. While prod control (§Cross-validation of report accuracy) covers "is the report factual?", this clause covers "what is that fact about?".

1. Distinguish two kinds of claims (organizational vocabulary)

• Operational claim — "Pipeline X works as …". The subject is the mechanism. Even when the verification input is a sample, the claim can be true.
• Artifact claim — "X artifact has been produced". The subject is the deliverable. True only if the underlying source is real (0 fixtures).
• If the underlying source is not real, it is not an artifact claim but an operational claim. This incident promoted an operational claim to an artifact claim.
• "Complete / final / done / produced" is used only for artifact claims. Self-check: "If I removed what I made, what stops working?" If the answer is a mechanism, the subject is a mechanism too.

2. Write DoD as a verification procedure, not a noun, and embed input status inside the sentence

• A noun-form DoD ("2-tenant artifact", "8-hour course design complete") automatically loses status in transit. Write procedurally — "Render 1 smoke sample and pass 8 gates" / "Verify via coverage-audit that 12 LOs are observable verbs and each has at least one assessment mapped; attach a log with 0 orphan LOs".
• Status (sample / real) is written inside the DoD sentence, not as a separate field. Putting it in a separate slot lets it drop during summarization — exactly the failure in this incident.
• Decision rule: If the source of the content is a real target (real customers, real data, real curriculum), it is real; if it is an invented example or validation fixture, it is sample. If unclear, sample (safe side). Completeness (draft / final) is a separate axis, handled by status.

3. Quote DoD verbatim, with file:line — Do not rephrase DoD wording during summarization or transit. If compression is needed, confirm with the original author. Rephrasing a DoD without quotation was the form this incident took; with a :119 quote alone, the loss would have been immediately visible.

4. One line of "actual input" in completion reports — When reporting DoD satisfaction, state the input used for verification truthfully ("Input = SAMPLE fixtures (2), real customer data (0)"). This is already known during verification, so cost is zero, and it structurally blocks the subject from slipping to the material at the completion stage.

5. The gate has two layers — mechanical + human judgment

• Layer 1 (mechanical): Items automatically verifiable via procedural DoD. Layer 2 (human judgment): Items that cannot be measured mechanically but determine quality — sequencing, difficulty, tone, design fit. Naming the reviewer, criteria, and signature makes these procedural too.
• Forcing only layer 1 hardens into formalism. Procedural DoD creates a pressure to "keep only what's verifiable", pushing judgment-required quality outside the DoD. A procedural DoD without layer 2 is considered incomplete.

Manual gate (2026-07-19 wording correction): The required artifact: sample|real field in knowledge/** frontmatter is validated by scripts/build-wiki-index.mjs (REQUIRED + collect() mapping + value enum + git-tracking consistency) and runs when a human runs npm run wiki:check (and wiki:build / wiki:serve, which call it first). No hooks or CI are in use (core.hooksPath empty · no .husky · no .github · 0 non-sample hooks — verified by Hanna 2026-07-19) — so commit / PR time does not auto-block. Its semantic axis differs from status (lifecycle), and it is also a different layer from §2's "status inside the sentence" (reporting / DoD) — not a replacement. A "change artifact status (sample → real)" row is added to operations/doc-registry.md. Limit: This gate covers only knowledge/** documents; assets/ is not traversed — agent returns and CEO reports are not subject to mechanical verification, and §1–5 are the only mechanism (however, "is there a quote / input line?" is something a third party can check immediately).

Wording correction history (2026-07-19, CEO-approved): When first added, this section described an "automatic gate", but no automatic execution path existed. This is exactly the §1 prohibition — promoting an operational claim to an artifact claim (flagged independently by Rei and Minho → verified by Eden and Hanna). To avoid leaving a normative document in a state that violates its own clause, we correct it to match the facts. The gate's actual introduction = 796c826. When hooks or CI are introduced, it will be re-promoted to "automatic gate", with the introduction commit SHA noted.

Domain addenda (defined in the owner documents; this clause is a pointer): External documents = per-number source tags ([measured: target · period · method] / [estimated: basis] / [example: not an actual outcome]; if all three are missing, delete the sentence) · case whitelist · template dummy values are substitution tokens · pre-send scan (Junseo) · charts = status on the chart surface · only measured values at full saturation · generation-stage required args (Jian) · visuals = labels get cropped so show on the content itself (placeholder-only style), template default = on (Doyun) · documents = frontmatter artifact + wiki:check + doc-registry (Bora).

On violation: Distinguish inaccurate (lost qualifier or status) from false (concealment). Inaccurate = record in reviews/<agent>.md + rubric rating; false = same basis as prod control (heavier than the violation). Self-report and self-referral are mitigating factors (otherwise the signal becomes "honesty is penalized", encouraging the next concealment). A downstream report caused by a DoD-wording deficit is not charged to the downstream — the control point is the DoD author.

Owner: Learning-outcome and alignment-DoD verification procedure spec = curriculum-architect · Technical DoD (pipelines, rendering, infrastructure) = principal-architect · implementation-lead · Product DoD = platform-product-manager · Synthesis and transit accuracy = orchestrator · Norm revision = this section.

Approval Authority

Hiring, promotion, termination and setting / revising company goals = final CEO approval (default). The team-lead and People Ops review and recommend. As trust accumulates, this is gradually relaxed toward team-lead-autonomous hiring.

Authoring standards: .claude/org/_authoring-spec.md (persona templates, validation specs, brand tone).