@crossplatformai/skills/skills/post-build-ship/references/workspace-pbs-enforcement.md

Reusable Agent Skills for CrossPlatform.ai projects.

# Workspace PBS V1 Interoperability

This reference preserves compatibility with the existing managed CrossPlatform.ai Workspace PBS v1
provider without changing the sibling Workspace implementation. Managed state supplements the
Framework workflow; Authorizing User approval and the lean admission contract remain authoritative.

## Mode Selection

Select `portable` or `managed` once before starting provider state. Portable is the default and uses
the five-section packet directly. Managed is selected only when all eight stable provider tools are
available in the authenticated Workspace root pane:

1. `pbs_begin`
2. `pbs_freeze_candidate`
3. `pbs_record_staged_candidate`
4. `pbs_launch_gate`
5. `pbs_submit_receipt`
6. `pbs_check_checkpoint`
7. `pbs_record_commit`
8. `pbs_get_workflow`

If the complete suite is not available before start, use portable admission. Never partially mirror
state. After managed state starts, provider failures are reported honestly rather than reconstructed
from prose.

The `pbs-admit --mode managed` result checks the same substantive Framework blockers and adds the
identity-mapping default. It does not call provider tools.

## Preserved Internal Identities

Workspace PBS v1 keeps these thirteen Business Brief identities internally:

1. `userConfirmedIntent`
2. `repositoryVerifiedFacts`
3. `primaryPlannerRecommendations`
4. `unresolvedQuestionsDisposition`
5. `uxImpact`
6. `dxImpact`
7. `experienceEvidence`
8. `scopeAndNonGoals`
9. `constraintsAndRepositoryRules`
10. `risksAndResolvedAssumptions`
11. `recommendationProvenance`
12. `noUnresolvedImplementationDecision`
13. `uxDxClaimToProofMapping`

The adapter maps the five compact Post sections to those identities. They are provider
interoperability fields, not thirteen human-visible labels or thirteen admission statuses. Do not
make portable plans reproduce them.

Preserve the provider's candidate-section identifiers:

- `implementationPlan`
- `acceptanceCriteria`
- `gateLaunchSpecifications`
- `qaPlan`
- `executionAndShipRequirements`
- `excludedRoadmapPointer`

Missing portable roadmap wording or future-gate prose is defaulted at the adapter boundary. It is
not a Framework blocker.

## Stable Provider Event Names

The sibling v1 service may expose these existing role identities:

- `plan-review`
- `qa`
- `implementation-approval`
- `commit-validation`

and these invocation identities:

- `plan-review`
- `minimum`
- `preliminary`
- `authoritative-final`
- `complete-rerun`
- `implementation-approval`
- `commit-validation`

along with checkpoints `before_mutation` and `before_commit_recording`.

Preserving a provider identity does not make that activity mandatory in the Framework contract.
Submit receipts only for activities that actually occurred. Never fabricate skipped peer review,
implementation approval, commit validation, reviewer metadata, or attestations to satisfy an
internal field.

## State And Authority

Use `pbs_get_workflow` to verify managed state in the authenticated root pane. Candidate and receipt
identities are correspondence evidence only. They never replace Authorizing User approval or make a
transport digest launch authority.

Record staged candidates and commits when the managed provider supports the actual workflow state.
Provider checkpoints supplement hunk ownership and final-tree checks; they do not turn optional
review into a gate. A sibling-provider limitation that cannot represent the approved no-review
workflow is an interoperability issue to report, not permission to fabricate evidence or change the
provider implementation from this package.

Direct standalone Ship remains portable unless the user explicitly supplies an active managed Build
handoff.