@polygraph/cursor-plugin 0.4.51

package/skills/polygraph/reference/publish-changes.md

@@ -0,0 +1,153 @@
+# Publishing Changes Reference
+
+The branch-to-PR flow: push branches, create draft PRs, mark them ready, and associate PRs created outside Polygraph. `push_branch`, `create_pr`, and `associate_pr` all require a `description` following the Session Description Policy — read [`session-description.md`](session-description.md) before writing one.
+
+## Push Branches
+
+Once work is complete in a repository, push the branch using `push_branch`. This must be done before creating a PR.
+
+**If `push_branch` fails, don't guess at the cause.** Report the tool's actual error to the user first. Only once the real cause is clear, offer to fall back to a manual `git push` — let the user decide, rather than falling back unprompted or asserting what a credential/token can or cannot do.
+
+`push_branch` pushes from the local checkout: for the repo you are in, that is your current working directory with your commits; for delegated repos, it is the Polygraph-managed clone the child agent worked in. There is no separate session copy of the current repo.
+
+**Parameters:**
+
+- `sessionId` (required): The Polygraph session ID
+- `repo` (required): Repository name or repository ID to push from
+- `branch` (required): Branch name to push to remote
+- `description` (required): A session description is required. Must follow the Session Description Policy.
+
+```
+push_branch(
+  sessionId: "<session-id>",
+  repo: "org/repo-name",
+  branch: "polygraph/ad5fa-add-user-preferences"
+)
+```
+
+## Create Draft PRs
+
+Create PRs for all repositories at once using `create_pr`. PRs are created as drafts with session metadata that links related PRs across repos. Branches must be pushed first. For fork PR creation or registration, include `targetRepository` on the PR spec to identify the repository that should receive the PR.
+
+**Parameters:**
+
+- `sessionId` (required): The Polygraph session ID
+- `prs` (required): Array of PR specifications, each containing:
+  - `owner` (required): GitHub repository owner
+  - `repo` (required): GitHub repository name
+  - `title` (required): PR title
+  - `body` (required): PR description (session metadata is appended automatically)
+  - `branch` (required): Branch name that was pushed
+  - `targetRepository` (optional): Target GitHub repository for fork PR creation or registration, as `owner/repo`. Omit for same-repository PRs.
+- `description` (required): Must follow the Session Description Policy.
+
+**PR title format (applies to parent and child agents):**
+
+- PR titles become squash-merge commit messages in most repos. They MUST follow the target repo's commit convention (e.g., Conventional Commits: `<type>(<scope>): <subject>`).
+- Do NOT add agent-identifier prefixes such as `[codex]`, `[claude]`, or `[opencode]` to PR titles. These prefixes violate commit-lint rules and pollute the git history.
+
+```
+create_pr(
+  sessionId: "<session-id>",
+  prs: [
+    {
+      owner: "org",
+      repo: "frontend",
+      title: "feat: Add user preferences UI",
+      body: "Part of multi-repo user preferences feature",
+      branch: "polygraph/ad5fa-add-user-preferences"
+    },
+    {
+      owner: "org",
+      repo: "backend",
+      title: "feat: Add user preferences API",
+      body: "Part of multi-repo user preferences feature",
+      branch: "polygraph/ad5fa-add-user-preferences"
+    }
+  ]
+)
+```
+
+For fork PR creation or registration, keep `owner` and `repo` set to the source repository that owns the pushed branch and set `targetRepository` to the target repository:
+
+```
+create_pr(
+  sessionId: "<session-id>",
+  prs: [
+    {
+      owner: "contributor",
+      repo: "frontend-fork",
+      targetRepository: "org/frontend",
+      title: "feat: Add user preferences UI",
+      body: "Part of multi-repo user preferences feature",
+      branch: "polygraph/ad5fa-add-user-preferences"
+    }
+  ]
+)
+```
+
+**After creating PRs**, always print the Polygraph session URL:
+
+```
+**Polygraph session:** POLYGRAPH_SESSION_URL
+```
+
+## Mark PRs Ready
+
+Once all changes are verified and ready to merge, use `mark_pr_ready` to transition PRs from DRAFT to OPEN status.
+
+**Parameters:**
+
+- `sessionId` (required): The Polygraph session ID
+- `prUrls` (required): Array of PR URLs to mark as ready for review
+
+```
+mark_pr_ready(
+  sessionId: "<session-id>",
+  prUrls: [
+    "https://github.com/org/frontend/pull/123",
+    "https://github.com/org/backend/pull/456"
+  ]
+)
+```
+
+**After marking PRs as ready**, always print the Polygraph session URL so the user can easily access the session overview. Call `show_session` and display:
+
+```
+**Polygraph session:** POLYGRAPH_SESSION_URL
+```
+
+Where `POLYGRAPH_SESSION_URL` is from `polygraphSessionUrl` in the response.
+
+## Associate Existing PRs
+
+Use `associate_pr` to link pull requests that were created outside of Polygraph (e.g., manually or by CI) to the current session. This is useful when PRs already exist for the branches in the session and you want Polygraph to track them.
+
+Provide either a `prUrl` to associate a specific PR, or a `branch` name plus `repo` to find and associate PRs for a source repository.
+
+**Parameters:**
+
+- `sessionId` (required): The Polygraph session ID
+- `prUrl` (optional): URL of an existing pull request to associate
+- `branch` (optional): Branch name to find and associate PRs for
+- `repo` (optional): Source repository for branch-based association. Required when using `branch` in a multi-repo session.
+- `description` (required): Must follow the Session Description Policy.
+
+```
+associate_pr(
+  sessionId: "<session-id>",
+  prUrl: "https://github.com/org/repo/pull/123"
+)
+```
+
+Or by branch:
+
+```
+associate_pr(
+  sessionId: "<session-id>",
+  repo: "org/repo",
+  branch: "feature/my-changes"
+)
+```
+
+**Returns** the list of PRs now associated with the session.

package/skills/polygraph/reference/sandboxing.md

@@ -0,0 +1,33 @@
+# Sandboxing in Polygraph Sessions
+
+Polygraph may run an agent session inside an OS-level sandbox, but not every session is sandboxed — whether it is on depends on the user's config (globally, per-agent, or per-repo). When it is on, writes are limited to the repository working tree, the session root (`~/.polygraph/sessions/<session-id>/`), the system temp directory, and a few allowlisted directories; network access is restricted to allowlisted hosts. In practice: binding a listening socket is denied (dev servers fail with `EPERM`), localhost servers are unreachable, and writes outside the allowlist are rejected. The user may not know whether this session is sandboxed.
+
+**Recognize sandbox denials — do not retry or work around them.** When a command fails in a sandbox-shaped way (`EPERM` binding a port, a blocked network host, a denied write to an ordinary path), the sandbox blocked it. Do NOT retry variations, escalate through workarounds, or route the command through `!`-prefixed user commands — those run inside the same sandbox. One failure is enough evidence; stop and inform the user.
+
+**Warn before attempting known-blocked operations.** Before starting a dev server, anything else that listens on a port, or an operation that needs writes or network access outside the allowlist, tell the user up front that it will not work while sandboxing is on and offer the options below instead of attempting it.
+
+**What to tell the user.** Explain that Polygraph runs this session in a sandbox, then present both options. Each takes effect on the next agent launch, so the Polygraph session must be relaunched afterwards:
+
+1. **Keep the sandbox on and allow the specific operation** (preferred). The sandbox belongs to the agent harness, so exceptions live in harness settings committed to the repository; array settings merge with Polygraph's generated allowlist rather than replacing it.
+
+   **If you are the Claude parent** — add writable paths to `.claude/settings.json` (or `.claude/settings.local.json`):
+
+   ```json
+   { "sandbox": { "filesystem": { "allowWrite": ["<path>"] } } }
+   ```
+
+   The `.claude/` directory is read-only inside the sandbox, so give the user the exact snippet to commit — you cannot apply it yourself.
+
+   **If you are the Codex parent** — add writable roots or network access to `.codex/config.toml`:
+
+   ```toml
+   [sandbox_workspace_write]
+   network_access = true
+   writable_roots = ["<path>"]
+   ```
+
+   The `.codex/` directory is read-only inside the sandbox, so give the user the exact snippet to commit — you cannot apply it yourself.
+
+2. **Turn sandboxing off.** The user quits the agent, runs `polygraph config`, toggles **Agent Options → Claude** (or **→ Codex**) **→ sandbox** off (or per-repo under **Repo Options**), and relaunches the Polygraph session. Non-interactive alternative: set `agentOptions.claude.sandbox: false` (or `agentOptions.codex.sandbox: false`, or `repoOptions."org/repo".sandbox: false`) in `~/.polygraph/config.json`. Warn that this removes filesystem isolation — the agent can then write anywhere the OS user can.
+
+**Never blame the tooling.** A sandbox denial means the environment blocked the operation — not that the repo, tool, or framework is broken. Do not record conclusions like "X is unusable" in memory, session descriptions, or messages based on sandboxed failures.

package/skills/polygraph/reference/session-by-commit.md

@@ -0,0 +1,25 @@
+# Finding the Session Behind a Commit or Line
+
+Use this workflow when the user asks which Polygraph session produced, is behind, or changed a particular commit — or a particular line of code.
+
+**Given a commit sha.** When the user names a sha, or asks what session is behind a commit, resolve it with `search_sessions` using the `sha` parameter (CLI: `polygraph session search --sha <sha>`):
+
+- Pass **exactly one** of `query` or `sha` — they are mutually exclusive.
+- `sha` accepts a full or partial sha, 7-40 hex chars.
+- The lookup is exact and one-shot: it returns the session(s) linked to that commit, newest first, scoped to the current org, and only explicit sessions.
+
+```
+search_sessions(sha: "a1b2c3d")
+# CLI equivalent:
+polygraph session search --sha a1b2c3d
+```
+
+**Given a line number.** There is no line-number lookup — a line MUST first be resolved to a commit sha with `git blame`, then that sha is fed into the sha lookup:
+
+1. `git blame -L <line>,<line> -- <file>` to get the commit that last touched the line.
+2. Pass that sha to `search_sessions(sha: ...)` (or `polygraph session search --sha <sha>`).
+
+**Reading the results.**
+
+- Multiple sessions may match a sha. They come back newest first — pick the most relevant one and report the others if they matter.
+- **A "no match" result does NOT prove the commit had no work behind it.** Not every commit is linked to an explicit session: commits pushed directly (rather than via an ingested PR) and gaps in ingestion metadata mean the sha may simply not be recorded, and implicit sessions are never returned. Report "no linked session found for that sha" — never assert that no work exists behind the commit.

package/skills/polygraph/reference/session-description.md

@@ -0,0 +1,111 @@
+# Session Description Reference
+
+## Session Description Policy
+
+`description` is user-facing Polygraph session context.
+
+`description` is required for `push_branch`, `create_pr`, and `associate_pr`, and is the primary input to `update_session` (which takes `title` and/or `description`). (`mark_pr_ready` does not take a description.) The Polygraph web app renders the description as Markdown, so use real Markdown headings — not flat `Label:` lines. Use the canonical structured format:
+
+```markdown
+## Goal
+
+<what the session is trying to accomplish>
+
+## Current progress
+
+<what has been completed so far, including PR/session state when relevant>
+
+## What worked
+
+<important decisions, approaches, or constraints that future agents should preserve>
+
+## Next steps
+
+<clear next implementation steps>
+```
+
+- Do not use a one-line feature summary for final handoff or PR creation in a multi-repo session.
+- Keep it concise but durable for a future resumed agent.
+- Prefer high-level state over file-by-file changelogs.
+- Mention unresolved decisions or risks when they matter.
+- In `Next steps`, include only next implementation steps. Do not list routine operational steps such as pushing branches, watching CI, or marking PRs ready.
+
+## Dual audience: humans now, agents later
+
+The description has two readers, and you must write for both:
+
+1. **Humans, in the web UI** — this is the primary surface. The app renders the description as Markdown for people scanning session state.
+2. **Agents, later** — the description is also read back by agents reconstructing session history (for example, on resume). They may not have the original working tree, branch, or local environment available.
+
+Because of the second audience, write **durably**:
+
+- Avoid ephemeral or local references (paths, ports, in-progress scratch state) that won't mean anything to a later reader.
+- Don't assume the original working tree is available — describe *what* changed and *why* at a level that survives without the diff in front of you.
+- Capture decisions and constraints, not just a snapshot of the current terminal.
+
+## Formatting building blocks
+
+Plain text (headings + prose + lists) remains the norm. The blocks below are available when they genuinely add clarity — reach for them only when they earn their place.
+
+### Headings, emphasis, lists
+
+Use the `##` headings from the canonical template. Use **bold**/*italic* for emphasis, and bullet or numbered lists for enumerations. Keep nesting shallow.
+
+### Callouts (GitHub alert syntax)
+
+The app maps each callout to a status color, so pick the right type:
+
+- `> [!WARNING]` / `> [!CAUTION]` — risky migrations, destructive operations, or **required manual steps** a reader must not miss.
+- `> [!NOTE]` / `> [!IMPORTANT]` — context, rationale, or a key constraint worth highlighting.
+- `> [!TIP]` — an optional helpful pointer.
+
+```markdown
+> [!WARNING]
+> The auth migration must run before deploying the API repo, or existing sessions are invalidated.
+```
+
+### Tables (GFM)
+
+Use a GitHub-Flavored Markdown table only for genuinely tabular data. The polygraph UI already shows per-PR state so avoid that. 
+
+```markdown
+| Repo        |  Change Type        |
+| ----------- |  ------------------ |
+| org/api     |  api functionality  |
+| org/web     |  text-only          |
+```
+
+### Mermaid diagrams
+
+The app renders fenced ` ```mermaid ` blocks as diagrams. Use one only when it genuinely clarifies session state. Good uses:
+
+- Control or data flow between logic pieces across repos or system components.
+- A sequence of changes, or migration order.
+- A state machine.
+
+> [!IMPORTANT]
+> Do NOT redraw the cross-repo dependency / repository graph. The app already renders the repo-relationship graph for every session, so a repo-relationship diagram in the description is redundant.
+
+Plain text remains the norm; diagrams are optional and never required.
+
+### Code blocks and task lists
+
+Use fenced code blocks for commands, signatures, or short snippets. Use task lists (`- [ ]` / `- [x]`) when tracking discrete remaining work items.
+
+### Links
+
+- Prefer durable external URLs (e.g. GitHub PRs/issues, Linear tickets).
+- Do NOT put local or dev links in the description: `localhost`, `127.0.0.1`, and `file://` URLs do not resolve in the UI and are useless to later readers.
+- Do NOT put repo-relative file paths (`./foo.ts`, `../bar`) as links — they don't resolve in the UI.
+- To attach supplementary references (PRs, issues, other Polygraph sessions, Linear tickets), use the `link_reference` tool instead of inline links. `link_reference` is **supplementary** to the description, not a replacement for it.
+
+## Updating the session description
+
+Before writing:
+
+- Read the current session details.
+- Consider the current conversation, child-agent results, PRs, pushed branches, validation, and unresolved decisions.
+- If appending a new item, read the current/latest description first and write the full replacement description with the existing items plus the new item.
+- If updating or replacing the existing last item, write the resulting state directly.
+
+Write the description using the canonical structured format above. Then call `update_session` or one of the other tools like `create_pr` that take a description as input.

package/skills/polygraph/reference/shallow-clone-history.md

@@ -0,0 +1,9 @@
+# Fetching Git History for Shallow Clones
+
+Session repos are shallow (`--depth 1`) clones, and plain `git fetch --unshallow` fails on private repos (the clone-time credential is not retained).
+
+When git fails on missing history — `bad object` from `git revert`, `git log`, `git blame`, etc. — call `git_fetch({ sessionId, repo })` (CLI: `polygraph git fetch <repo> --session <id> --json`), then retry the git command.
+
+- Defaults fetch the default branch's full history.
+- Pass `depth` for a bounded fetch, or `refs` to include extra branches.
+- Safe to call redundantly — returns `alreadyComplete: true` when the history is already present.

package/skills/session-debrief/SKILL.md

@@ -0,0 +1,57 @@
+---
+name: session-debrief
+description: Analyze the raw logs of past Polygraph sessions and produce structured, rank-ordered debriefs for use in a different session. Use when launched (typically as a background agent) with a ranked list of relevant Polygraph session IDs and a statement of the current task; pulls parent and child transcripts via the polygraph CLI and returns one consolidated debrief.
+---
+
+# Session Debrief
+
+You produce debriefs of PAST Polygraph sessions so a parent agent working on a NEW task can decide what context is relevant. You are read-only with respect to the inspected sessions: never resume them, never spawn agents into them, never push branches, create PRs, or update their descriptions.
+
+## Input
+
+- A ranked list of sessions `{ sessionId, title?, url? }`, most relevant first (rank 1 = most relevant). If no explicit ranking is stated, the given order IS the ranking.
+- A statement of the current task the parent is working on.
+
+## Procedure
+
+Speed matters: the parent agent keeps working while it waits for you, and it folds your debrief in whenever it lands.
+
+**Single session (the usual case).** The parent normally launches one background debrief agent per related session, so your input will usually contain exactly one session. Run the "Debriefing one session" steps directly — do not spawn a subagent for a single session.
+
+**Multiple sessions: fan out.** When given more than one session, debrief them CONCURRENTLY, never one after another: spawn one subagent per session, all in a single message so they run in parallel. Give each subagent: its session entry (sessionId, title, url, rank), the current-task statement, the "Debriefing one session" steps, and the per-session output template — copied into its prompt, since it cannot see this skill. Each subagent returns its completed debrief section as its final message. Assemble the returned sections in rank order and return them; do not rewrite them. Only if your environment cannot spawn subagents, run the "Debriefing one session" steps yourself, sequentially in rank order.
+
+### Debriefing one session
+
+Invoke the CLI as `${POLYGRAPH_CLI:-polygraph}` in every command: when the session was launched from a specific CLI build, `POLYGRAPH_CLI` points at it and children must use the same one. When you copy these steps into a subagent prompt, keep the `${POLYGRAPH_CLI:-polygraph}` form verbatim.
+
+1. `${POLYGRAPH_CLI:-polygraph} session show --details <sessionId>` — metadata, description timeline, repositories, PRs. The description timeline often already summarizes goals and outcomes; mine it before reading transcripts.
+2. Duplicate-work check: if the metadata shows this session pursuing the SAME task as the current one (not merely related work) and it is unfinished or recently active, do NOT read the transcripts. Return the debrief section immediately, with `**DUPLICATE WORK IN FLIGHT**` as the first line after the heading, followed by the session's status and last activity, one line of evidence for the match, and what resuming it would restore. The parent halts and asks the user to choose between resuming that session and continuing the current one, so speed matters more than depth here.
+3. `${POLYGRAPH_CLI:-polygraph} session logs -s <sessionId> --all --tail none > "$TMPDIR/<sessionId>-logs.txt" 2>&1` — the parent transcript plus every child transcript, rendered as plain text, in ONE call. Then read the file directly (with offsets for large files). Do NOT fetch `--json` and do NOT query the transcript with node/python one-liners — reading the rendered text is faster and you extract while reading. **Coverage caveat:** `session logs --all` covers default-role children only — agents spawned with a `role` keep their transcripts local to the machine that ran them (viewable there via `polygraph agent attach --role <role>`); if the session used such agents, note in the debrief that their work is not visible in these logs.
+4. Write the debrief section (format below).
+
+Large transcripts: read the file in a few large chunks, prioritizing user prompts, assistant text and final messages, tool errors and failure events, and task notifications. Routine tool-use noise (file reads, searches) is safe to skim. Do not make repeated small queries against the transcript; each round trip costs more than reading a bigger chunk.
+
+## Output
+
+Return ONE consolidated debrief as your final message — it is consumed by the parent agent, not shown raw to a human. Sessions in rank order, each following this template. Target a tight page per session; do not pad.
+
+### Rank N — <session title> (<sessionId>)
+
+**DUPLICATE WORK IN FLIGHT** — only when the duplicate-work check fired: status, last activity, one-line evidence. Omit this line otherwise.
+**URL:** <session url>
+**Goal:** what the session set out to do.
+**What happened:** condensed narrative of the work performed.
+**Outcome + artifacts:** PRs (URL + status), branches, key files touched.
+**Key decisions:** one bullet per decision, with the recorded rationale.
+**Gotchas / failed approaches:** what went wrong or was abandoned, and why.
+**Unresolved:** open items or next steps the session left behind.
+**Relevance to current task:** one or two sentences connecting this session to the stated task. The parent decides what to use — report the connection, do not overclaim.
+
+## Constraints
+
+- Exact citations: session URLs, PR URLs, file paths, branch names.
+- If a session's logs are hidden or unavailable, say which (`hidden: true` in the CLI output means hidden by the author; empty steps mean no logs uploaded) and debrief from `session show --details` metadata, description timeline, and PRs alone.
+- No speculation: when the transcript does not show why a decision was made, write "rationale not recorded".
+- Read-only: the inspected sessions must be byte-for-byte unaffected by your work.
+- Session data only: debrief from what the CLI and MCP tools return (metadata, description timeline, transcripts, PRs). Do NOT read repository code, run git or gh, or fetch PR diffs to verify claims — report what the session shows and leave verification to the parent.
+- Fail fast: if a CLI command errors, retry it once at most, then report the error verbatim in your debrief section and move on. Do not build workarounds (no copying auth/config to a fake HOME, no POLYGRAPH_ROOT redirection, no privilege or sandbox escapes) — a debrief that says "logs unavailable: <error>" is more useful than one that arrives late.

package/skills/session-start/SKILL.md

@@ -0,0 +1,53 @@
+---
+name: session-start
+description: Start or reconnect a Polygraph session for shared, resumable agent context. Use when the user asks to start a Polygraph session, create session memory, share or resume work context, include related repositories, or inspect an existing session before continuing.
+
+---
+
+# Start a Polygraph Session
+
+Start or reconnect a Polygraph session so the current work has shared, resumable context: session URL, repository graph visibility, linked PR/CI state, and the option to expand across repository boundaries when needed.
+
+## Check Authentication First
+
+Before session work, the parent conversation must check Polygraph auth with `whoami` or `polygraph whoami`.
+
+- If auth is valid and an organization is selected, continue.
+- If auth is missing, expired, or no organization is selected, stop session work. Do not keep trying session creation or discovery.
+- Facilitate user reauth through the browser-based flow, such as `polygraph auth login` or the MCP `login` equivalent. After login, make sure an organization is selected with `polygraph account select` or the MCP equivalent when needed.
+- Re-run `whoami` after reauth. Continue only after it confirms a valid login and selected organization.
+
+Do not breeze past auth failures. In Codex Desktop, auth recovery usually requires the user to complete the browser login flow; surface that clearly and wait for it before continuing.
+
+## Parent Session Detection
+
+The parent conversation is responsible for detecting an existing Polygraph session ID from the current context, startup banner, or user-provided session URL/ID, then passing that `sessionId` explicitly to `polygraph-init-subagent` when launching it. The init subagent cannot infer the parent's current session context by itself.
+
+For a fresh Codex Desktop conversation started with `/polygraph:session-start`, no `sessionId` is expected. Launch `polygraph-init-subagent` without `sessionId` so it creates a new session.
+
+## Decide the Session Path
+
+Pick one path before using tools.
+
+1. **Existing session with repos** - If a Polygraph session ID is already in scope and the user did not ask to add repositories, pick by intent: to continue the session's work from this conversation, join it via `resume_session`; to only inspect it, call `show_session` and print the session details. Do not create a new session.
+2. **Existing session, adding exact repository refs** - If a session ID is in scope and the user provided exact refs by ID, short name, full name, GitHub `owner/repo` slug, URL-like slug, or MCP resource syntax, call `add_repo(sessionId, repoIds: [...])` directly. Do not run discovery.
+3. **Existing session, discovery needed** - If a session ID is in scope but repos need to be discovered or selected, launch `polygraph-init-subagent` with the existing `sessionId` and `userContext`. The subagent must use `add_repo`, not `start_session`.
+4. **No session in scope** - Launch `polygraph-init-subagent` with `userContext` and no `sessionId`. The subagent will discover related repositories when needed and call `start_session`.
+
+Exact refs are not limited to organization repos. Public open-source repos can be added by `owner/repo` slug or URL even if they do not appear in repository discovery.
+
+If there is no subagent mechanism, use `list_repos` only when discovery is needed, then call `start_session` for a new session or `add_repo` for an existing session.
+
+## Print the Result
+
+When a brand-new session is created, render the session welcome card. Prefer the `session_intro` MCP tool when available; otherwise run `polygraph session intro -s <sessionId>` and print the returned markdown verbatim.
+
+For an existing or reconnected session, print:
+
+**Session:** POLYGRAPH_SESSION_URL
+
+**Repositories in this session:**
+
+- REPO_FULL_NAME
+
+Use `polygraphSessionUrl` from the session response for `POLYGRAPH_SESSION_URL`, and use repository entries from the session response for `REPO_FULL_NAME`.