# `MishkaDocument.Section`
[🔗](https://github.com/mishka-group/mishka_document/blob/v0.0.1/lib/mishka_document/resources/section.ex#L5)

Manages documentation sections within workspace versions.

This resource represents hierarchical sections that organize documentation content.
Each section belongs to a specific workspace version and can have parent-child relationships
for nested organization. Sections support content and technical review workflows with
multiple approval states.

The resource includes comprehensive metadata management with SEO tags, Schema.org
structured data, and multi-language support. Database-level constraints ensure data
integrity with slug validation and proper ordering.

Multi-tenant isolation ensures sections are properly segregated between sites.

# `t`

```elixir
@type t() :: %MishkaDocument.Section{
  __lateral_join_source__: term(),
  __meta__: term(),
  __metadata__: term(),
  __order__: term(),
  aggregates: term(),
  approved_section_draft_count: term(),
  archived_at: term(),
  breadcrumb_path: term(),
  calculations: term(),
  change_version: term(),
  child_sections: term(),
  content: term(),
  content_classes: term(),
  content_components: term(),
  content_icons: term(),
  content_review_status: term(),
  content_word_count: term(),
  contributors_count: term(),
  effective_permissions: term(),
  front_page: term(),
  group_heading: term(),
  group_page: term(),
  id: term(),
  inserted_at: term(),
  language: term(),
  language_group_id: term(),
  language_group_section: term(),
  language_variants: term(),
  last_modified_at: term(),
  latest_note_archived_at: term(),
  latest_note_change_at: term(),
  lineage_versions: term(),
  master_language_group_section: term(),
  master_notes: term(),
  master_parent_section: term(),
  master_section_drafts: term(),
  master_source_section: term(),
  master_tags: term(),
  master_tags_join_assoc: term(),
  master_workspace_version: term(),
  note_drafts: term(),
  notes: term(),
  order_position: term(),
  parent_section: term(),
  parent_section_id: term(),
  pending_note_draft_content_review_count: term(),
  pending_note_draft_technical_review_count: term(),
  pending_section_draft_content_review_count: term(),
  pending_section_draft_technical_review_count: term(),
  permissions: term(),
  rendered_content: term(),
  schema: term(),
  section_drafts: term(),
  section_lineage_id: term(),
  section_versions_count: term(),
  seo_tags: term(),
  site: term(),
  site_id: term(),
  slug: term(),
  source_section: term(),
  source_section_id: term(),
  tags: term(),
  tags_join_assoc: term(),
  technical_review_status: term(),
  tenant_notes: term(),
  tenant_tags: term(),
  tenant_tags_join_assoc: term(),
  title: term(),
  updated_at: term(),
  workspace_version: term(),
  workspace_version_id: term()
}
```

# `__guarded_change__`

Apply the full GuardedStruct pipeline (sanitize → validate → derive →
main_validator) to `attrs` and return either `{:ok, transformed_attrs}`
or `{:error, errors}`. Wire this into an `Ash.Resource.Change` to plug
guardedstruct rules into Ash's changeset pipeline.

The function is named `__guarded_change__` because it does more than
validate — it can also transform values (trim, downcase, slugify,
auto-fill, etc.) before they reach the data layer.

# `__guarded_field_meta__`

O(1) lookup of a field's compile-time metadata by name. Returns
`nil` for unknown fields.

# `__guarded_field_name_set__`

Compile-time-baked `MapSet` of every field name owned by the
`guardedstruct` block. Used by `GuardedStruct.AshResource.Change`
to decide, in O(1), whether a key in `changeset.atomics`
belongs to the pipeline.

# `default_short_name`

# `input`

```elixir
@spec input(values :: map() | Keyword.t()) :: map() | no_return()
```

Validates that the keys in the provided input are valid for at least one action on the resource.

Raises a KeyError error at compile time if not. This exists because generally a struct should only ever
be created by Ash as a result of a successful action. You should not be creating records manually in code,
e.g `%MyResource{value: 1, value: 2}`. Generally that is fine, but often with embedded resources it is nice
to be able to validate the keys that are being provided, e.g

```elixir
Resource
|> Ash.Changeset.for_create(:create, %{embedded: EmbeddedResource.input(foo: 1, bar: 2)})
|> Ash.create()
```

# `input`

```elixir
@spec input(values :: map() | Keyword.t(), action :: atom()) :: map() | no_return()
```

Same as `input/1`, except restricts the keys to values accepted by the action provided.

# `json_api_match_route`

# `primary_key_matches?`

---

*Consult [api-reference.md](api-reference.md) for complete listing*