/**
 * method-catalog-owner-profile.ts
 *
 * Contract descriptors for the owner profile (`profile.*`), what the platform
 * knows about the person who owns it, kept as one Markdown file at daemon scope.
 * See docs/owner-profile.md §11.1 for the verb table these descriptors implement.
 *
 * Descriptors live here (static) so buildOperatorContract / api.md / the
 * generated contract artifacts see them whether or not a handler has been
 * attached yet; routes/owner-profile.ts attaches the handlers when the runtime
 * composition root builds the store. Same descriptor/handler split as
 * method-catalog-principals.ts.
 *
 * Two properties of this surface are deliberate and are asserted by tests:
 *
 *  - **`profile.status` never returns a value.** It is the diagnostic verb, so
 *    it answers with load state, path, section names, counts and the invalid
 *    field list WITH REASONS, and nothing that could carry a shipping address
 *    into a diagnostics bundle. Its output schema has no `value` anywhere.
 *  - **There is no enumerate-all-people verb.** `profile.person` takes a name.
 *    `profile.read` returns everything and is the "what do you know about me"
 *    answer to the owner, which is exactly the call a composition path must not
 *    make (§10). The absence of a `profile.people.list` is load-bearing, not an
 *    oversight.
 *  - **`profile.read` carries its own scope**, `read:profile-document`, rather
 *    than sharing `read:profile` with the named lookups. §11.2 asserts it "is
 *    not callable from a composition path at all", and while nothing here can
 *    decide which token a composition path is handed, a separate scope is what
 *    makes that assertion expressible: the bulk read can be withheld while
 *    `get`, `person`, `provenance` and `status` are granted. Without it the
 *    claim had no mechanism behind it whatsoever, every profile read sat at
 *    one scope.
 *
 *    The name is flat and UNRELATED, deliberately not `read:profile.full`.
 *    `scopeMatches` (daemon-sdk/route-helpers.ts) grants on an exact match, on
 *    `*`, or on a `prefix:*` wildcard; there is no dotted hierarchy anywhere in
 *    the platform, and `read:profile.full` was its only dotted scope. That name
 *    read as "profile, but more" while granting its holder none of the plain
 *    `read:profile` verbs, a token minted with the apparent superset would
 *    have taken 403s on `get`, `person`, `provenance` and `status`. It is
 *    masked today only because `getGrantedGatewayScopes` unions every declared
 *    scope, so real tokens hold both; it would surface the moment a caller
 *    passed an explicit list.
 */
import type { GatewayMethodDescriptor } from './method-catalog-shared.js';
/** Where a line came from: which surface, when, and the owner's exact words. */
export declare const PROFILE_PROVENANCE_SCHEMA: Record<string, unknown>;
/**
 * The same provenance, where the runtime answers an explicit `null`.
 *
 * `profile.provenance` returns `ProfileProvenanceReport`, whose `provenance` is
 * `ProfileProvenance | null`, a hand-edited field carries `handEdited: true`
 * and a null source. The schema declared a plain object, so a strict client
 * validating that answer failed with `field "$.provenance" expected object but
 * received null` on every hand-edited field, in exactly the way `profile.get`
 * failed on `$.field.section`.
 *
 * Declared nullable rather than dropped from the payload, and nullable in the
 * same shape `reason` already uses on the write result: the null is the store's
 * own three-state answer (recorded / hand-edited / not present at all), and
 * removing the property would change the bytes on the wire for every client
 * that already handles it.
 *
 * Everywhere else provenance is OMITTED when there is none rather than sent as
 * null, the field views, the prose lines, the superseded lines, so those keep
 * the non-nullable schema and say exactly what they send.
 */
export declare const NULLABLE_PROFILE_PROVENANCE_SCHEMA: Record<string, unknown>;
/** One prose line, preserved as written. */
export declare const PROFILE_LINE_SCHEMA: Record<string, unknown>;
/** One mechanical field. `valid: false` still carries the value, see §4.3. */
export declare const PROFILE_FIELD_SCHEMA: Record<string, unknown>;
/**
 * One mechanical field as `profile.get` answers it: everything the read view
 * carries, plus the heading it was found under.
 *
 * `section` is real data, it comes from the fields registry, and it is the
 * answer to "whereabouts in my profile is that written". It is DECLARED here
 * rather than stripped from the payload or waved through by loosening
 * `additionalProperties`, because a client that cannot see the property is no
 * better served than one that fails on it.
 *
 * Its own schema rather than an optional property on {@link
 * PROFILE_FIELD_SCHEMA}, because that one is also `profile.read`'s, and
 * `profile.read` does not send `section`, it groups fields under their
 * heading, so repeating it on each field would be noise. Adding a property to
 * THAT response would break every client still validating against the
 * previously published contract: the same failure this schema exists to fix,
 * pointed at a different verb.
 */
export declare const PROFILE_FIELD_DETAIL_SCHEMA: Record<string, unknown>;
/** One `## ` section, with its tier so a caller knows what it is holding. */
export declare const PROFILE_SECTION_SCHEMA: Record<string, unknown>;
/** A mechanical value that did not validate, and why. Never fails the file. */
export declare const PROFILE_INVALID_FIELD_SCHEMA: Record<string, unknown>;
/**
 * Load state. `kind` is `loaded` | `unavailable` | `disabled`; the counts belong
 * to `loaded` and `reason` to `unavailable`.
 *
 * No `value` property, and none nested anywhere below: this is the shape
 * `profile.status` answers with, and it is the reason that verb is safe to put
 * in a diagnostics bundle.
 */
export declare const PROFILE_STATE_SCHEMA: Record<string, unknown>;
/** A `<!-- was: … -->` predecessor, retained so `profile.undo` has something to promote. */
export declare const PROFILE_SUPERSEDED_SCHEMA: Record<string, unknown>;
/** One thing a write did. Names the field; never repeats the value. */
export declare const PROFILE_CHANGE_SCHEMA: Record<string, unknown>;
/** What every write verb answers. `ok: false` always carries a reason. */
export declare const PROFILE_WRITE_RESULT_SCHEMA: Record<string, unknown>;
export declare const PROFILE_READ_INPUT_SCHEMA: Record<string, unknown>;
export declare const PROFILE_READ_OUTPUT_SCHEMA: Record<string, unknown>;
export declare const PROFILE_GET_INPUT_SCHEMA: Record<string, unknown>;
export declare const PROFILE_GET_OUTPUT_SCHEMA: Record<string, unknown>;
export declare const PROFILE_PERSON_INPUT_SCHEMA: Record<string, unknown>;
export declare const PROFILE_PERSON_OUTPUT_SCHEMA: Record<string, unknown>;
export declare const PROFILE_PROVENANCE_INPUT_SCHEMA: Record<string, unknown>;
export declare const PROFILE_PROVENANCE_OUTPUT_SCHEMA: Record<string, unknown>;
/**
 * `authority` is REQUIRED on all four write verbs, and the required arrays below
 * say so because the handler enforces it.
 *
 * It shipped in `properties` but in none of the `required` arrays, so the
 * generated contract, the OpenAPI document and every typed client told callers
 * the field was optional while `routes/owner-profile.ts` answered 400 without
 * it, a client that followed the published contract was broken by
 * construction. `owner-profile-verbs.test.ts` pins all four against the live
 * descriptors so the two cannot drift apart again.
 *
 * Required rather than defaulted because §7 gives `forget` and `undo` an
 * authority check and nothing else: an omitted authority on a delete was not a
 * weakened gate, it was no gate.
 */
export declare const PROFILE_SET_INPUT_SCHEMA: Record<string, unknown>;
export declare const PROFILE_APPEND_INPUT_SCHEMA: Record<string, unknown>;
/**
 * A prose line is addressed by its CONTENT, its section plus its exact text,
 * and never by its position. `lineIndex` is not a parameter here or of any
 * other verb.
 *
 * §3: the owner is a concurrent writer. An index is only valid against the file
 * state that produced it, and between a `profile.read` and a
 * `profile.forget` the owner can add a line in their editor and shift everything below
 * it. The positional delete then removes the wrong line and reports success,
 * the false-receipt class §9.2 exists to prevent, arriving through the front
 * door. No validation can catch it, because a stale index is perfectly
 * well-formed; only content addressing closes it.
 *
 * `ProfileLine.lineIndex` stays in the in-memory model and in read output, the
 * writer splices by it, but §5.1 is explicit that it describes the model, not
 * the reachable surface.
 */
export declare const PROFILE_FORGET_INPUT_SCHEMA: Record<string, unknown>;
export declare const PROFILE_UNDO_INPUT_SCHEMA: Record<string, unknown>;
export declare const PROFILE_STATUS_INPUT_SCHEMA: Record<string, unknown>;
export declare const builtinGatewayOwnerProfileMethodDescriptors: readonly GatewayMethodDescriptor[];
//# sourceMappingURL=method-catalog-owner-profile.d.ts.map