# Verified YouTube Community queue

This starter kit installs the KittyClaw queue used by the verified publisher workflow. It separates editorial preparation from browser-based publication and uses the real publisher states: `A valider`, `Programme`, `Publie`, `Rejete` and `Echec`.

## Prerequisites

- A KittyClaw project for editorial planning.
- A second KittyClaw project for the publication queue.
- A browser runner signed in to the intended YouTube channel.
- One reviewed JSON content file for each planned publication.
- Credentials stored outside tickets, content files and public evidence.

## Install the KittyClaw publication board

Keep the calendar and original request on the editorial board. Start with a separate, empty KittyClaw project for publication, then run:

```sh
node install-workflow.mjs \
  --project <publication-project-slug> \
  --workspace <publication-project-workspace> \
  --tools-root <yt-community-publisher-workspace>
```

The installer checks that the three real publisher tools exist, creates any missing columns and installs the two deterministic automations in `.agents/automations.json`. Each automation receives `YT_BOARD_PROJECT` and `YT_POSTS_DIR`, so it acts on the project you selected and stores its queue data in that project's workspace. The installer preserves unrelated automations and can be run again safely.

The installed route matches the CLI and processors:

`A valider -> Programme -> Publie`

`Rejete` records a suspended type or a spacing conflict. `Echec` records a publication failure that needs correction and resubmission.

The rules implemented by the supplied publisher processors are:

- `A valider -> Programme`: the type is allowed and no item for the same channel falls inside the spacing window.
- `A valider -> Rejete`: the type is suspended or the requested slot conflicts with another item for that channel.
- `Programme -> Publie`: the scheduled time and policy allow publication, links are reachable, the browser uses the requested channel, and the result is verified.
- `Programme -> Echec`: a non-transient publication check fails. Identity mismatches retry in place up to the publisher's configured limit before entering `Echec`.

## Files

- `config.example.json`: queue policy and proof contract.
- `editorial-calendar.example.md`: two-week planning template.
- `post.example.json`: minimal post content file.
- `poll.example.json`: minimal poll content file.
- `qa-checklist.md`: publication checklist.
- `workflow.example.json`: exact columns and automations installed by the bootstrap command.
- `install-workflow.mjs`: repeatable installer for a clean KittyClaw publication project.

## Flow

1. Create the JSON content file in the editorial repository. The publisher CLI calls this file a `payload`.
2. Record its planned slot and source ticket in the calendar.
3. Submit it to a dedicated publisher queue. Copy the payload into an immutable or versioned publisher location.
4. Run editorial and factual review before scheduling.
5. Reject any slot within `minimumSpacingHours` of another item for the same channel.
6. Before browser automation, assert that the active YouTube identity matches the configured channel.
7. Publish, then verify the item in YouTube Studio. A successful click is not proof.
8. Write the publication timestamp, verification result and public channel URL back to the source ticket.

## Submission with the verified publisher CLI

The workflow used the `yt-submit.mjs` CLI from the `yt-community-publisher` project. Run it after copying your reviewed payload to a path the CLI can read. Use the same project slug and workspace that you passed to the installer:

```sh
YT_BOARD_PROJECT=<publication-project-slug> \
YT_POSTS_DIR=<publication-project-workspace>/posts \
node <yt-community-publisher-workspace>/.agents/tools/yt-submit.mjs \
  --source <project> --ticket <id> --payload <file.json> \
  --channel <configured-channel> --at <ISO-8601> \
  [--type <article|annonce|recap|sondage|teaser|engagement>] [--lang fr]
```

The CLI derives the publication format automatically: a payload with `poll.options` is labeled `poll`; a payload without it is labeled `post`. The optional `--type` flag is an editorial category, not the payload format. Replace `<configured-channel>` with a key present in the publisher's channel configuration; the verified workflow used `kalceo`.

The CLI validates JSON, freezes the payload in `YT_POSTS_DIR`, creates a review ticket in `YT_BOARD_PROJECT` and stores provenance. The validation and publication processors read the same two variables from the installed automations. Keep cookies, session identifiers and browser-profile paths out of the payload. If you implement another adapter, preserve these semantics and document its accepted channel and type vocabularies.

## Required states

`A valider -> Programme -> Publie`

Use `Rejete` for a policy rejection and `Echec` for an exhausted or non-transient failure. Only enter `Publie` after the publisher has read the Studio result and returned confirmation to the source ticket.

## Recovery

If the wrong browser identity is active, abort without publishing, capture a redacted diagnostic, switch to the intended channel and rerun identity validation. If selectors drift, preserve the payload, update the browser adapter, test without publishing, then retry the same queue item. In both cases, retain the failed attempt in the audit trail.

## Measurement without PII

Track queue events such as `submitted`, `qa_passed`, `cadence_passed`, `publish_attempted`, `verified` and `proof_returned`. Do not attach viewer, cookie, account-session or browser-profile data.