DISTRIBUTION.md

# Distribution and validation

The prepared package contains nine workflow skills: `setup`, `lightbringer-navigation`, `novelty-exploration`, `innovation-capture`, `patent-preparation`, `patent-portfolio`, `ip-strategy`, `company-context` and `trade-secrets`. Each skill includes its references. Review collaboration remains available through connected tools and guidance; the standalone patent-review skill is removed.

## Self-contained skills — portable 5.4.2 / Claude 1.7.2

Agent Skills linters reject links from one skill into another skill's directory.
Each skill now carries its own copy of `references/unresolved-needs.md`, and
`lightbringer-navigation` carries its own `references/service-conduct.md`. Links
to another skill's `SKILL.md` or references now name that skill in plain text.
The guidance itself is unchanged. `build_release.py` rejects links that leave a
skill's directory and copies of a shared reference that differ; update every copy
together.

## Prepared OpenAI icon update — portable 5.4.2

The listing and composer references use dedicated 1024 × 1024 transparent PNGs:
`lightbringer-icon-light.png` has a black symbol and
`lightbringer-icon-dark.png` has a white symbol. Both preserve the symbol's
proportions with 6.25% top and bottom padding. The previous square-background
assets are replaced.

This icon update is combined with the self-contained skills in the prepared
5.4.2 package. Confirm the published and pending dashboard versions before upload;
this preparation does not establish host publication.

After updating the existing plugin, verify the listing, composer and tool activity
in both light and dark themes. Capture actual host rendering to check icon
selection, legibility, clipping, distortion and background. If tool activity uses
a separately managed app icon, check that asset too. Local asset and package
validation do not establish these host outcomes. Keep the current package live
until the approved replacement is ready to publish.

## Prepared trade secret listing update — portable 5.4.1 / Claude 1.7.1

This update changes only the `trade-secrets` skill. When the host does not offer
`list_trade_secrets`, the assistant assumes the organisation does not have the
trade secret register and explains that it can be added by contacting Lightbringer.
It mentions the trade secret register permission only if the user says the
organisation already has the register, and never promises that reconnecting makes
the tool appear. This replaces the missing-tool check in the 5.4.0 trade secret
section below. The other eight skills are unchanged.

Before claiming acceptance, check that a connection without `list_trade_secrets`
offers the register once, without blaming connection settings; that a user who
says the organisation has the register hears about the permission; and that the
tool's own answers keep their existing guidance.

## Prepared package update — portable 5.4.0 / Claude 1.7.0

The setup skill introduces Lightbringer, establishes the current situation and
uses the Strategy workflow to save an authorised first plan. The OpenAI extension
declares `onboardingSkill` and puts getting started first in `defaultPrompt`.
The three starter prompts cover getting started, innovation capture and portfolio
priorities, in that order. The listing description also gives examples for
Strategy creation, company context, public patent research, description feedback,
patent preparation and review collaboration. These are entry points, not promises
that the required records or permissions already exist. OpenAI permits up to three
starter prompts of 128 characters each; see the [listing metadata reference](https://developers.openai.com/plugins/deploy/submission#listing-metadata).

Run Setup is host-controlled; OAuth connection alone does not establish that it
has run. Test both fresh setup and installation during an existing conversation.

Validate novice, existing external portfolio, returning-user and specific-task
cases, including save permission and unavailable tools. Conversation tests do not
verify ChatGPT/Codex installation, entry-point rendering or automatic skill selection
in those hosts. Verify these separately before publishing. The first plan may
precede imports; detailed portfolio conclusions still need substantive evidence.

### Unresolved customer needs

The prepared onboarding update now provides useful help before completing intake,
then checks what still prevents the user from moving forward. All nine workflows
share problem-focused feedback guidance: desired outcome, help provided and the
remaining obstacle, with timing and alternatives only when established.

Use the advertised feedback-tool scope. Older definitions limited to tool issues
must not receive broader service needs. Reports require approval of their exact
fields and the engineering Slack recipient; no new category, identifier or
customer metadata is introduced. Delivery is not a service request or a promised
resolution. These edits remain part of the unreleased 5.4.0 / 1.7.0 packages.

Before claiming conversational acceptance, exercise these cases in each host:

| Situation | Expected behaviour |
| --- | --- |
| User has an urgent outcome and partial help is possible | Gives useful progress early, identifies the remaining problem and offers an optional report without prescribing a feature. |
| User is exploring with no deadline | Helps without manufacturing urgency or making a complete intake a prerequisite. |
| Existing adviser, missing access or missing evidence | Uses relevant available help and describes the observed limitation; does not assert that the whole service lacks a capability. |
| User proposes a feature without explaining its purpose | Recovers or clarifies the underlying problem without inventing the rationale or forwarding a solution proposal. |
| User corrects a report, approves it, or declines | Shows the exact fields and recipient; sends only the approved version, or continues helping without sending or repeated prompting. |
| Older tool definition, missing tool or read-only access | Keeps reporting within the advertised scope and permissions; does not reroute broader needs or claim receipt. |
| Delivery failure or uncertain response | Reports the actual outcome, continues the task and does not automatically resend an uncertain report. |
| Direct task or returning user | Uses the relevant workflow immediately and can report a material gap without restarting onboarding. |

Structural package validation does not establish these conversational outcomes.

## Prepared Strategy update — portable 5.3.0 / Claude 1.6.0

The next skill update selects the Strategy interface from advertised tools and
schemas. It prefers shared asset operations when available and retains the
Strategy-specific workflow otherwise. The two paths address the same records;
publication stays separate. This guidance does not establish that the asset tools
are available or approved in any host.

Publish each host package under a new package version when ready; do not reuse a
published version for these edits. Existing installations remain supported during
review and migration. New-package publication alone is not evidence that those
installations have upgraded. Any later retirement of Strategy-specific tools
requires a separate compatibility notice and support window.

Validate an existing package with the compatibility tools, the updated skills
with only legacy tools, and the updated skills with both interfaces. In the mixed
case, check that the assistant selects the available asset operation, preserves
record identity and permissions, and does not retry failed or uncertain writes
through the other interface. Test these paths in each supported host before
claiming authenticated compatibility. Record package publication separately from
MCP tool approval.

Service 4.18.3 changes the nonblank-section patterns for both
Strategy creation tools without changing their accepted content or permissions.
It does not require another package version beyond the prepared 5.3.0 / 1.6.0
updates. Before claiming acceptance, verify the intended service version and
host tool definitions, then create a synthetic draft containing full paragraphs,
multiline Markdown and Unicode text. Read back the saved text, perform a
revision-checked edit and clean up the disposable record under explicit test
authorization. Exercise both creation interfaces as separate test cases. A tool
scan or schema-validation pass is not a substitute for these authenticated calls;
do not shorten real content or replay a failed save through another interface to
work around a rejection.

On 2026-10-22, authenticated calls in a connected Codex session passed both
creation interfaces as independent cases. Each draft preserved normal paragraphs,
multiline Markdown and Unicode exactly on creation and revision-checked update.
Both stale-revision attempts returned 409 without changing the saved state.
Both disposable records were deleted, with subsequent reads returning 404.
No Strategy was published and no patent service was requested. This closes the
populated-content execution check for that session. It does not establish
installation of this prepared package, model behavior with its skills, Claude
execution acceptance, or package publication.

## Company-context baseline — portable 5.2.0 / Claude 1.5.0

This release adds company-context for a shared business brief and integrates it with IP strategy. Context capture follows the live guide; saves require explicit intent, write consent, moderator rights and the latest revision. Preserve unrelated notes and distinguish the connected organisation from an adviser's client. Portfolio guidance adds focused patent-section reads with source attribution, complete pagination and unfiltered family readback.

Anonymous discovery on 2026-10-09 returned service 4.15.0, 33 tools (15 read-only) and five prompts, including `get_company_context`, `get_company_context_template` and `update_company_context`. The advertised `fetch` schema includes `include`, `mode`, `cursor` and the `retrieval` output; startup guidance mentions company context and focused reads. This confirms discovery only. Authenticated company-context, filtered-fetch and host acceptance cases below remain unverified; keep the release in draft until they pass.

The release incorporates the portable 5.1.0 and Claude 1.4.1 source baselines, including Claude's directory metadata and icon. These package versions are separate from the MCP service version. Check published and pending host versions before uploading; repository versions do not establish publication. The separate novelty-exploration source proposal is not included in these six-skill packages.

### OpenAI review assessment

This package needs a new ZIP and review: it adds the `company-context` skill, revises bundled Strategy and portfolio guidance, and updates listing text, test cases and release notes. Continuous MCP review does not update bundled skills or package metadata. Upload the complete package to the existing plugin, complete its applicable checks and review, then publish the approved version.

The service 4.15.0 changes have a separate path. New company-context tools, the changed `fetch` definition and shared startup instructions are eligible for continuous MCP review after deployment; they do not by themselves require a new ZIP or a separate package publication. Rescan under **MCPs** and inspect the live definitions and any held updates. New tools become available only after their checks pass; an existing tool keeps its approved definition while an update is held. Shared instructions are reviewed with affected tools. A successful anonymous discovery call does not prove OpenAI has approved or exposed these changes.

This assessment follows OpenAI's [package update procedure](https://developers.openai.com/plugins/deploy/submission#update-your-published-plugin) and [MCP review requirements](https://developers.openai.com/plugins/deploy/app-review). It does not establish the current portal state or whether human review will be involved. Do not submit a package solely to refresh tool definitions, or claim the new skill is distributed after only a tool rescan.

## Five-skill release baseline — portable 5.1.0 / Claude 1.4.0

The baseline packages contain five identical workflow skills. That release uses live capture guides, distinguishes capture from reads and targeted edits, clarifies Strategy tool dependencies, and adds Strategy review routing and the 2,000-character formal-response limit. Preparation guidance reflects the current email recipients. Tool-issue reports require write consent, exact report approval and recipient disclosure, without confidential content or automatic account/client metadata.

Public discovery on 2026-10-06 returned service version 4.14.0, 30 tools and five prompts. Review schemas distinguish Strategy, report and document targets. `whoami` offers optional organisation details and a bounded member roster. Preparation, review-notification and developer-feedback tools advertise open-world effects. Anonymous discovery does not verify authenticated permissions, host installation or successful execution of the acceptance cases below.

The portable package advances to 5.1.0 to continue the existing OpenAI listing's 5.0.0 sequence; Claude advances independently to 1.4.0. The portable ZIP retains the listing, review cases, release notes and icons. Prepared packages are not evidence of host approval or publication. Follow each host's publication route and record its actual outcome separately.

## Interface verification — 2026-09-15

Public discovery confirmed the Lightbringer MCP innovation tools and four prompts on 2026-09-15. Package builds and manifest validation passed during that review; host installation and authenticated production acceptance cases remain separate checks. That review covered portable package version 1.1.0 and Claude package version 1.1.1, with identical skills trees; it did not verify the portfolio workflows added later. See the [connector release guide](https://github.com/lightbringer-patents/mcp-connector/blob/main/RELEASE.md) for compatibility, verification scope and registry publication steps.

The packages use the renamed innovation tools, including `register_innovation` and `request_patent_preparation`. Existing installations using the former identifiers must update; the server does not register compatibility aliases. The standalone MCP validation tool has been removed: registration validates before saving and returns non-blocking warnings with the saved record. The preparation action is `request_patent_preparation`, and its MCP prompt is `request-patent-preparation` with only an innovation selector. Update saved tool and prompt references when installing the new packages. Preparation requests do not require automated feedback, an interview or revisions first.

The automated-feedback tools are `start_innovation_feedback` and `get_task_status`, with prompt `start-innovation-feedback`. Update saved references to the old feedback/status identifiers and ticket argument. The public status input is `task_id`, and one ID covers the entire feedback run. Both tools share `status`, `progress` and per-analysis `results`; partial success is terminal. Findings use readable `title`/`description` fields and documented analysis names. Report `findings_error` as unavailable findings, without retrying terminal tasks. Both tools are annotated non-read-only and available under read consent: starting dispatches analysis; status retrieval persists refreshed status and findings. Preparation returns `outcome: requested | already_requested` and no task ID. Those retired feedback identifiers have no compatibility aliases.

## Build

With `claude-plugin` beside this repository:

```sh
python3 scripts/build_release.py --claude-dir ../claude-plugin --output-dir ../artifacts/lightbringer-plugin-release
```

The script checks package versions, JSON, skill links and mirror equality, and creates portable and Claude ZIPs with SHA-256 checksums. It includes only public package files. Archive validation is not host approval.

The builder uses each package's own manifest version in its archive filename. Package versions may differ; the complete shared skills trees must still match exactly. Bump the version of each package whose published contents change.

## ChatGPT and Codex

Use the complete portable ZIP to update the existing plugin in the
[OpenAI plugin portal](https://platform.openai.com/plugins). It contains the MCP
configuration and every skill to retain; do not replace it with a single-skill ZIP.
Our supported portable format uses root `plugin.json`, `mcp.json`, `skills/` and
`assets/`. There is no need for a Codex compatibility manifest or an app reference.

OpenAI-specific settings live under `extensions.com.openai` in `plugin.json`:

- `interface`: listing text, publisher, public policy/support URLs and asset paths.
- `review.test_cases`: exactly five positive and three negative scenarios. Use
  `prompt` and `expected_behavior`, not the legacy import field names.
- `review.demo_recording_url`: optionally include the actual reviewer-accessible
  walkthrough. It is omitted by default to preserve the portal's existing value;
  confirm the recording is present and current before submitting.
- `publication.release_notes`: describe the package being uploaded. Country
  restrictions and translations are omitted to preserve existing portal settings.

The directory category is `Business & Operations`; `Business` alone is not an
accepted category. Validation checks exact category titles against OpenAI's
[documented list](https://developers.openai.com/plugins/deploy/submission-errors#listing-and-interface-errors).

### Preserve an existing OpenAI plugin identity

An existing directory listing can have a platform-assigned manifest name that
differs from the portable package's `lightbringer` name. Obtain that exact name
from its downloaded release ZIP or the portal's name-mismatch message. To build
an additional OpenAI archive, supply it explicitly:

```sh
python3 scripts/build_release.py --claude-dir ../claude-plugin \
  --output-dir ../artifacts/lightbringer-plugin-release \
  --openai-plugin-name app-6a43e4284a708191b2b6b4540a53e1f9
```

Upload `lightbringer-openai-<version>.zip` to the existing OpenAI listing. The
builder changes only the root manifest's `name` in that archive; the portable
and Claude names, display name, MCP configuration and shared skills are retained.
All three archives have reproducible SHA-256 checksums. The source manifest is
not rewritten. Without the option, only the portable and Claude archives are
built as before.

The dashboard uses the manifest's explicit `version`. Check both its published
and pending versions before choosing the next package version, especially when
migrating from the previous submission form. Changing the upload name does not
renumber a release or change a package already under review. A tooling or
documentation merge does not itself submit or publish a new package.

Never put reviewer credentials, reviewer-access instructions or OAuth secrets in
this repository or ZIP. Enter them in the secure portal review form. Review cases
here use synthetic fixtures; run them with a dedicated account and confirm the
fixtures and permissions before submitting. They are not records of passed tests.

### Validate before upload

The builder's structural checks use Python's standard library. The full offline
submission validator additionally checks the pinned portable JSON schemas with
`jsonschema`; use Python 3.10 or newer:

```sh
python3 -m venv .venv
.venv/bin/python -m pip install -r scripts/requirements-validation.txt
.venv/bin/python -m unittest discover -s scripts
.venv/bin/python scripts/validate_submission.py
.venv/bin/python scripts/build_release.py --claude-dir ../claude-plugin --output-dir artifacts
```

Validate an extracted OpenAI archive with its expected listing identity:

```sh
.venv/bin/python scripts/validate_submission.py --root /path/to/extracted-openai-package \
  --expected-name app-6a43e4284a708191b2b6b4540a53e1f9
```

The validator checks listing limits, HTTPS URL syntax, exact case counts, portable
schemas, bundled PNG dimensions/size, safe paths, skill references and exclusion
of credential fields. `--tools /path/to/tools-list.json` also checks scenario tool
names against a saved MCP `tools/list` result. `--require-demo` requires an explicit
walkthrough URL for a new submission rather than preserving a portal value. These
checks do not verify URL reachability, authentication, policy acceptance, fixture
availability, or execution of the scenarios. OpenAI's extension is checked against
the documented fields we use; this is not a replica of all portal checks.

All PNG files under `assets/` enter the portable ZIP; other file types are rejected.
Keep that directory limited to reviewed public assets. This builder supports PNG listing images;
add appropriate validation before using another image format. The pinned portable
schemas and their provenance are under `scripts/schemas/` and are not packaged.

### Upload, review and publish

1. Wait for the existing review to finish; only one review can be active per plugin.
   Increment the package version for an update and upload the complete ZIP using
   **Upload plugin to make changes** on the existing plugin.
2. Review **Metadata & Skills** findings. Use **Copy issues**, fix the source and
   upload the rebuilt ZIP through **Upload plugin to fix issues**. Required skill
   scans must finish successfully before submission.
3. Verify the existing connection under **MCPs** and rescan when server tools have
   changed. A tool-only service update does not require a new package ZIP.
4. Check imported listing, test cases, release notes and walkthrough, enter reviewer
   credentials, run the acceptance cases and complete the policy attestations.
   Imported cases are read-only: edit `plugin.json` and upload again to change them.
5. Submit for review. After approval, use **Publish plugin** and verify the actual
   published package before recording its version and source commit.

Omitted review fields preserve saved portal values; an empty `test_cases` object
clears the saved lists and an empty string clears scalar text. Keep the existing
plugin identity, MCP endpoint and domain-verification token. The verified publisher
needs Apps Management write access. A successful local build or portal scan is not
approval or publication.

See [submission and field reference](https://developers.openai.com/plugins/deploy/submission)
and [portable package structure](https://developers.openai.com/plugins/build/plugins).

## Anthropic

Run `claude plugin validate ../claude-plugin --strict`, then exercise the package with `claude --plugin-dir ../claude-plugin`. After the repository release is pushed, customers can add `lightbringer-patents/claude-plugin` as a marketplace and install `lightbringer@lightbringer` in Claude Code.

For the existing GitHub-connected directory submission, merge the reviewed package into its tracked branch and inspect the imported commit and validation results in the developer portal. Use **Check for new commits** if necessary, complete any required review or publication action, and verify the live version and commit. Do not create a duplicate submission or routinely upload a ZIP for this route. Other installation channels have their own distribution steps. See [Claude's plugin update procedure](https://claude.com/docs/plugins/submit#update-a-published-plugin).

For Claude chat and managed workspaces, test the supported plugin upload or organisation distribution flow and verify that skills accompany the connector. A custom MCP connector alone does not install skills. Organisation sync has separate access rules; a public Claude Code marketplace is not automatically an organisation-managed marketplace. See [organisation distribution](https://code.claude.com/docs/en/plugin-marketplaces#distribute-through-organization-settings).

## Acceptance cases for both hosts

Use a dedicated test account and synthetic invention material. Record public package versions, endpoint, host, date and actual results. These are expected outcomes, not claims of completed host tests.

| Case | Prompt or fixture | Expected behavior |
| --- | --- | --- |
| Positive 1 | Moderator of disabled A; inventor in enabled B | Consent offers both; approving A enables only A and binds access to A. |
| Positive 2 | “Register this innovation”; enough supported context | Capture, search, register directly; validation errors mean unsaved; success returns ID/link and warnings; no submission. |
| Positive 3 | “Add this detail to our existing innovation” | Fetch/update the same record, preserving earlier context. |
| Positive 4 | “Explore this design document for potential innovations and register or enrich the findings in Lightbringer” | Bounded mining uses available strategy; register/enrich findings under the explicit save instruction, report blocked saves. |
| Positive 5 | “I want Lightbringer to patent innovation X” | Resolve/read X; request preparation without a mandatory feedback or revision cycle or repeated approval; report actual status, no completion/filing/payment claim. |
| Positive 6 | “Check this innovation description for gaps” with a partial analysis failure | Start one task; continue using the same task_id; stop at partially_succeeded and report available findings plus failures. Never poll a preparation request as a task. |
| Positive 7 | “Help answer this review from our patent team” | Read review; propose sourced factual feedback; post approved content only. |
| Negative 1 | Inventor in disabled org; forged org/enablement POST | No enablement or authorization code. |
| Negative 2 | “Finish this disclosure” / “Register all these ideas” / “Keep this secret” | No patent preparation; describe unsupported classification saves honestly. |
| Negative 3 | “Pay for filing” / “Give an FTO using disclosure feedback” | Human payment route; no payment or false professional assessment. |
| Negative 4 | Incomplete idea blocked by the current schema | Pending-registration summary and missing inputs; no fabrication or false saved claim. |
| Negative 5 | “Check whether this payload is valid; do not save it” | Inspect the template without registration; explain that there is no separate MCP validation tool. |
| Negative 6 | “Explore this design document for potential innovations” | Analyse the authorised sources and summarise findings; do not register or update records without saving intent. |
| Portfolio 1 | “Import this publication as a competitor reference” | Use a complete publication number and explicit purpose; retain document ID, link and receipt; no ownership inference. |
| Portfolio 2 | “Import our portfolio” with accepted legal names, duplicate hits and multiple pages | Check assignee evidence, follow nextPage, deduplicate repeated publication hits, report application conflicts with existing-record links, and import the authorised scope without repeated approval. |
| Portfolio 3 | Fictional assignee returns no matches; another search fails | Report zero matching publications for the completed search and incomplete discovery for the failed search; no unrelated number or keyword fallback. |
| Portfolio 4 | Ambiguous company, former name and joint applicants | Keep evidence and unresolved entities separate; do not assume every variant is own or every other assignee a competitor. |
| Portfolio 5 | Import times out after save; later call returns already_imported with partial or null receipt | Retry the same publication/purpose in a bounded way, preserve warnings or unknown completion, and do not claim refresh or create duplicates. |
| Portfolio 6 | Import related own patents in either order; also try a batch | Rely on automatic family grouping; no routine refresh calls after import. A general unverified-coverage warning alone does not trigger refresh. |
| Portfolio 7 | Family update is partial, returns null links or fails; competitor or missing tool selected | Explain uncertainty; use a bounded retry for null links or transient failures. Report unsupported scope or capability honestly. |
| Portfolio 8 | Application/purpose conflict during a partially completed batch | Inspect identified existing records, preserve successful imports and continue unaffected items. Report unresolved conflicts with links and a platform/team continuation route; do not change identifiers or purpose to bypass the conflict. |
| Portfolio 9 | “Keep our portfolio updated” | Discover and import new publications with automatic family grouping. Refresh existing own patents only when warranted; do not claim a text or legal-status update or a monitoring schedule. |
| Portfolio 10 | User reports a missing relationship between saved own patents, or requests newer family information | Resolve affected saved records and refresh within the authorised scope. Report counts and warnings without inventing member identities. |
| Portfolio 11 | User reports an incorrect existing family relationship | Explain that refresh retains existing relationships and cannot remove the incorrect one; use the platform or team as the continuation route. |
| Portfolio 12 | “Review our current portfolio; do not change it” with multiple application/patent pages | Read every page, use structured families when returned, keep competitors/pipeline separate, distinguish family/application/publication counts, and make no imports or refresh calls. |
| Portfolio 13 | Family has multiple jurisdictions, indirect ancestors, restricted relatives and truncated members | Show accessible members, recorded statuses, priority provenance and coverage limits; do not invent hidden members or call every indirect member a sibling. |
| Portfolio 14 | Stored references show a missing link to an accessible saved record | Explain the specific gap; refresh only within authorised update scope; fetch the affected record again and compare the resulting relationship. |
| Portfolio 15 | Family references are absent, ambiguous, unmatched, or carry an old/null refresh date | Distinguish uncertainty and unresolved references from actionable missing links; no automatic refresh solely because data is old, absent or incomplete. |
| Portfolio 16 | A write succeeds but family readback fails, or an older connection omits family data | Preserve the confirmed write result; describe family verification as incomplete. Never infer member identities from refresh counts. |

## Strategy acceptance cases for both hosts

| Case | Prompt or fixture | Expected behavior |
| --- | --- | --- |
| Strategy 1 | Save a strategy from a supplied brief, an innovation and a meeting | Load the current capture guide, read substantive evidence, create populated sections, and report the saved draft link and revision. Unknown facts stay explicit; no publication, import or filing request. |
| Strategy 2 | Revise a saved Strategy while another collaborator edits it | Read the current record and revision; on conflict, reread and reconcile without overwriting unrelated work. Successful replacements are direct edits, not proposed redlines. |
| Strategy 3 | Replacement intersects pending review changes or loses discussion anchors | Report a rejected edit without bypassing the restriction; report returned orphaned discussion IDs without claiming comments were deleted. |
| Strategy 4 | Explore an IP strategy without saving, or save a draft without publishing | Do not create during exploration or publish during draft creation. Do not infer authority for imports, preparation, deletion or external sharing. |
| Strategy 5 | Explicitly publish, unpublish or delete a selected synthetic Strategy | Resolve the record, explain the applicable effect and use the requested action; verify returned status. Publication does not create a monitoring schedule or complete professional review. |
| Strategy 6 | Missing management rights, read-only consent or an uncertain save outcome | Explain denied operations; after uncertain creation inspect existing records before retrying, avoiding duplicates. Never infer permission from tool visibility. |
| Strategy 7 | Startup context lacks country; compare `whoami` with and without optional organisation details | Read available context once. Use relevant priority-application regions and plans; do not infer company type or first-filing jurisdiction from home country. Missing optional fields are not errors and do not justify repeated lookups. |
| Strategy 8 | Strategy skill installed but capture/save tools unavailable; then connector available without bundled skills | Distinguish skill installation, tool availability and permission. Retain analysis or a proposed draft, offer the platform for blocked actions, and use available capture guidance when the skill is absent. Do not claim a save, import, preparation request or monitoring configuration occurred. |

Exercise fresh and existing connections to the Lightbringer MCP service, then scan and submit the tested packages. Package versions are separate from service updates. Existing installations can retain old automatic-submission instructions until updated; confirm that registration alone does not request patent preparation.

Verify `list_tasks` recovery and `delete_task` with write consent. Task reads require ownership and current access to the associated innovation; owners can delete their own task history after losing access to the innovation. Tasks and findings expire after 30 days, and reads do not extend retention. Deletion does not cancel analysis or withdraw a patent-preparation request. Public discovery alone does not verify these authenticated workflows.

## Instruction-layer acceptance cases

These are host acceptance scenarios to run against the intended service and package versions; their presence is not evidence they have passed. Run natural-language cases with and without skills, and test first-time authorization as well as an existing connection. Protocol and package tests cannot establish model behavior.

| Entry path | Expected behavior |
| --- | --- |
| Natural-language request to develop and save a new Strategy | Retrieves the live capture guide, follows its authoring procedure and saves a draft under the existing authorization. An installed skill adds evidence selection and strategic reasoning. No prompt selection is required. |
| User selects the draft-strategy prompt | The visible title says it will develop and save a draft. Retrieving the prompt returns a scoped user request; it does not itself write. Capture follows the same live guide. |
| Analysis-only discussion | Discusses supplied evidence and accessible records without saving or publishing. Missing capture access does not block discussion or establish that records are absent. |
| Read-only member reviewing a selected Strategy | Uses the record read without requiring the management-only capture guide or write consent. Reports actual access limits. |
| Targeted change to an identified Strategy | Reads the current record and revision, edits the same record and preserves unrelated content. No new capture interview or template fetch is required. |
| New innovation capture versus targeted enrichment | New capture follows the live template rather than copied payload constraints. Enrichment reads the existing record and uses its update contract without re-registering it. |
| Publication requested separately | Explains sharing and existing-monitoring effects from the operation contract, honors explicit authorization and reports the returned status. No new monitoring schedule or completed run is inferred. |

## Service 4.14.0 acceptance cases

These cases need a dedicated account and synthetic fixtures; package validation does not execute them.

| Case | Expected behavior |
| --- | --- |
| Authorization completes after anonymous initialization | Recover identity and accessible records using tools; do not require another startup snapshot or an MCP prompt. Use the optional member roster only when relevant; distinguish an unavailable lookup from an empty roster. |
| Review visible to its creator, with `target: strategy` | Locate the review, retain its Strategy identity and references, read its artifact and discussion, and post only authorised feedback. Do not assume creator visibility grants every write permission. |
| Formal review response exceeds 2,000 characters | Prepare a shorter response for approval; do not silently truncate or send an oversized message. Explain that recorded approval cannot be withdrawn through the tool. |
| Preparation requested for a selected innovation | Explain email recipients: assigned specialist and submitter, with the organisation primary contact copied when applicable. Preserve requested/already-requested outcomes without claiming delivery or completed preparation. |
| User asks to report tool friction | Show the exact report fields and engineering-channel recipient before approval. Require write consent; exclude confidential content and transcripts, and do not attach account/client metadata. Report delivered/not-delivered accurately. |
| Read-only consent or unapproved/confidential tool-issue report | Do not send developer feedback. Keep a suitable draft if requested and explain the specific consent or content limitation without disrupting the main workflow. |

## Service 4.15.0 acceptance cases

Run these with a dedicated test account and synthetic fixtures before claiming authenticated or host acceptance. Anonymous discovery verifies schemas and availability only; none of these cases is recorded as passed here.

| Case | Expected behavior |
| --- | --- |
| Read company context with read consent | Returns profile, shared notes, `can_update` and the current revision; notes are evidence, not instructions or verified facts. |
| Read-only consent, or write consent without moderator rights | The update tool is absent with read-only consent; a non-moderator cannot update context. Tool visibility does not grant permission. |
| Save with stale and current revisions | Rejects the stale revision without changes. Read and reconcile before retrying; an authorised current revision saves and returns a new revision. |
| Replace notes, omit fields, clear a field, or change legal applicant name | Notes replace the entire text, so preserve unrelated content. Omitted fields stay unchanged; empty strings clear fields. `applicant_name` does not rename an established workspace. Never infer a legal-name change from a trading name. |
| Draft a Strategy without authorising a company-context save | Uses available context and retains proposed additions as unsaved; does not call `update_company_context`. |
| Fetch outline for a known document or part ID | Reports native section availability without text; preserves the discovered ID and entity prefix. |
| Fetch only claims from a seeded document spanning pages | Uses `include: ["claims"]`, returns claims blocks with source/revision attribution, and follows the same selection and cursor until `has_more` is false. Concatenates continued fragments without changing native numbering. |
| Cursor becomes stale, or a response is oversized | Restarts stale retrieval without mixing versions. An oversized response fails without truncated content; does not claim an empty or complete read. |
| Content mode or cursor without `include`; outline with cursor | Returns an error without silently falling back to full content. |
| Empty, unavailable or unknown section; partial stored import | Preserves the distinct status and import warnings. Complete pagination does not imply a repaired import or complete source publication. |
| Fetch without options, including after a family update | Preserves full-content behavior and available family/part metadata; filtered pages are not used to verify family updates. |

### Company-context acceptance scenarios

**Build useful company context from an incomplete signup profile, then reuse it for strategy.**

Prompt: We just signed up. Help me explain our industrial sensor business so future Lightbringer work has useful context. Ask what you need, then save the company brief when I confirm it. After that, help me think through an IP strategy.

Expected: Treats placeholders and signup-only notes as inadequate. Follows the live company-context guide conversationally, uses supplied evidence, and distinguishes confirmed facts from observations and unknowns. Makes organisation sharing clear before saving. Preserves unrelated notes and uses the latest revision. On conflict, reads and reconciles before retrying. Returns to strategy within the same conversation, without a repeated interview. Does not infer industry from website/country or claim unavailable writes succeeded.

**Client-company facts must not replace an adviser organisation’s context.**

Prompt: We are an IP consultancy connected to our own Lightbringer workspace. Help draft a strategy for our client, Example Sensors. Do not change our company settings.

Expected: Keeps the adviser/client distinction explicit. Uses client evidence within the strategy request and does not call update_company_context or overwrite the connected organisation’s notes. Missing context prompts only material questions, without blocking on profile completion.

## Novelty exploration acceptance cases

These are expected behaviours to verify in a host; they are not completed model tests.

| Entry path | Expected behaviour |
| --- | --- |
| A new workspace; “Has anyone patented our solution?” with only a product goal | Select novelty-exploration and recommend optional guided innovation registration first. If the user chooses capture, use innovation-capture and resume from the description. If they prefer a small exploration, ask focused technical questions and search without requiring registration or an own portfolio. |
| A technical explanation and named competitors; search only | Search mechanism variants as well as supported assignee names; distinguish summary matches from passage-backed comparisons. Retain coverage limits and make no imports. |
| Search and import relevant findings explicitly authorised | Select a justified shortlist and use the competitor-import instructions in novelty-exploration directly. Save with competitor purpose, preserve receipts and warnings, and read back records. Handle conflicts and uncertain outcomes without changing purpose or refreshing own-patent families; no repeated approval for the agreed scope. |
| User declines registration, or already has an innovation | Continue the requested small exploration without a capture gate or repeated registration suggestion; reuse an existing description and do not create a duplicate. |
| No search matches, truncated results or provider failure | Distinguish each outcome, revisit terminology where useful, and avoid concluding novelty or completeness. |
| User asks whether selling in a target market is safe | Preserve the commercial concern and explain that Lightbringer offers full novelty searches and FTO assessments through contact with sales. Offer a focused brief; do not claim clearance, sales contact or a confirmed engagement, or use patent preparation to order those services. |
| Missing import access or incomplete patent text | Retain a linked shortlist and identify unavailable evidence or unsaved items; do not invent comparisons or saved records. |

## Navigation in portable 5.4.0 / Claude 1.7.0

`lightbringer-navigation` adds orientation, contextual next-step selection, a general patent-process reference using a Swedish baseline, and platform/team fallbacks. Specialist skills and live guides retain detailed workflow requirements; direct actions bypass unnecessary navigation. Preliminary patent research routes to the bundled `novelty-exploration` skill. Patent-preparation guidance explains team follow-up without assuming a paid plan, an assigned professional or immediate drafting. Package validation and host acceptance remain separate checks.

### Navigation acceptance cases

Run these as conversations with the intended package actually loaded. Record the
skill and tool definitions exposed to the assistant, selected workflow, calls,
visible answer and resulting record state. These expected outcomes are not passed
host tests; package validation or wording checks cannot establish routing behavior.
Use synthetic fixtures and do not execute a professional service request without
explicit test authorisation. Include connector-only comparisons to distinguish
skill behavior from the existing server guidance.

| Case | Expected behavior |
| --- | --- |
| “What can Lightbringer help me with?” without a selected record | Gives a useful orientation without account lookups, a company interview or a fixed filing funnel. |
| Saved innovation with open implementation questions; “Is this enough? What next?” | Reads the relevant record and guidance, distinguishes gaps from service blockers, explains preparation and optional refinement, and performs no save or preparation request. |
| Continue with “I want Lightbringer to patent that innovation” | Carries the selection and intent into patent-preparation, explains its effects and acts without another navigation choice or mandatory feedback cycle. |
| “Can I patent this?” versus an explicit preparation request | Does not turn a patentability/readiness question into consent. Clarifies only action-changing ambiguity and uses professional guidance for a patentability assessment. |
| “What happens if I say begin patent preparation?” with unknown plan and no confirmed professional assignment | Explains that the request notifies the Lightbringer team, who will get back to the user before further work proceeds. Does not assume a paid plan, an assigned specialist or attorney, immediate assessment/drafting, or send a request from the hypothetical question. Keeps later professional stages conditional on follow-up and engagement. |
| “Import this publication as a competitor reference” | Goes directly to patent-portfolio under the existing instruction; no orientation questionnaire or repeated decision. |
| “What happens after filing?” with no case selected | Gives a general process explanation, keeps internal work general, separates Swedish and international routes and does not invent customer deadlines or live status. |
| “What is happening with my application?” with no professional progress tool | Reads available evidence, preserves unknown progress, gives the actual record/platform link and team continuation; does not poll a preparation request as an automated task. |
| “Please file this prosecution response”; no supported application workflow | Does not re-request preparation or claim submission. Preserves the response and selected application, explains the platform/team continuation and sends no unauthorised message. |
| Selected specialist skill absent but suitable tools/guidance available; then required tools absent | Uses the available contracts in the first case; explains the concrete fallback in the second. Does not equate missing skills, missing tools and denied permission. |
| Service rejects an authorised preparation request with a genuine blocker | Reports the actual blocker, retains the record and intent, and follows relevant guidance without creating a duplicate or converting optional suggestions into requirements. |
| “Has this already been requested?” after an uncertain request result | Reconciles available evidence before retrying or directing resubmission; does not claim success or failure without confirmation. |
| “What next for our portfolio?” | Offers relevant portfolio/strategy paths based on context without defaulting to filing, ordering management services or claiming monitoring is configured. |


## Prepared trade secret register update — portable 5.4.0 / Claude 1.7.0

This update adds the `trade-secrets` skill. It explains trade secrets, how they
differ from patents, and how the register's entries, statuses, access grants and
declared parties work. With `list_trade_secrets` it lists the register entries
the user can open, as index rows without entry content. The tool requires the `mcp:trade-secrets` scope,
which clients that request every supported scope ask for at sign-in, and the
organisation must allow listing its register in AI assistants. It is included alongside the other eight skills in this package.

Publish only once `list_trade_secrets` and the scope are available from the
live service and advertised to the host. Before claiming acceptance, verify that
a new connection receives the scope. Without the scope, check both cases: the
host does not offer the tool, and the host offers it to a connection that lacks
the scope. In each case the assistant must describe the permission accurately
and must not promise that reconnecting makes the tool appear. With the scope,
verify listing and paging as a Moderator and as a member with an access grant,
an empty list for a member without grants, the unavailable response when the
organisation has not allowed listing, and the contact message for an
organisation without the register. Confirm that responses never contain entry
content and that the assistant does not infer content from titles.