Trademark Rename Plan

[sassdawe]

Planning assumptions:

The fork should stop shipping Microsoft-owned product names, extension IDs, package IDs, tool commands, and branding strings unless they are required only as historical references during migration.
Renames should be staged so that client and server protocol changes are validated before the next wave begins.
Existing automated tests and current manual notebook scenarios should be reused as phase gates wherever possible.

Phased Rename Plan

This plan assumes the fork will adopt a new neutral brand and execute renames in waves, validating after each wave before moving on.

Goals

• Remove Microsoft-owned product naming from shipped components in this fork.
• Avoid a single large rename that obscures client/server breakpoints.
• Preserve a working branch after every phase.
• Use existing automated and manual validation before expanding scope.

Naming Strategy Before Any Code Change

Pick and freeze the replacement vocabulary first. Do not start renaming until the replacement map is agreed and written down.

Minimum required map:

• organization/publisher prefix
• core engine name replacing .NET Interactive
• CLI tool command replacing dotnet-interactive
• VS Code extension ID and display name replacing dotnet-interactive-vscode and Polyglot Notebooks
• .NET root namespace prefix replacing Microsoft.DotNet.Interactive
• TypeScript/browser symbol prefix replacing DotnetInteractive*
• npm package scope/name replacements for @microsoft/polyglot-notebooks and microsoft.dotnet.interactive.js
• notebook type IDs and Jupyter kernel titles

Deliverable before implementation:

• one rename dictionary mapping every old public identifier to its replacement

Recommended fields in the rename dictionary:

• old identifier
• new identifier
• identifier class: artifact, public API, runtime protocol, persisted ID, or docs-only
• owning path or package
• first phase in which it changes
• whether a compatibility alias is required
• last phase in which the old name is still supported
• validation command or test proving the new name works

Cross-Phase Operating Rules

These rules keep the rename effort attributable and reversible.

1. Change only one identity layer per phase.
2. Do not combine artifact renames and public API renames in the same commit unless a clean build is otherwise impossible.
3. For any rename that crosses a client-server seam, prefer a dual-name compatibility window for one phase.
4. Treat persisted IDs differently from source names.
   • source names can be renamed aggressively once tests pass
   • persisted IDs need migration or dual registration
5. Do not sweep docs and samples during runtime phases unless they are needed as test fixtures.
6. Every phase must end with a branch state that can be tagged and used as a recovery point.

Compatibility Policy

Not every old name needs a compatibility shim. Use this policy to decide.

Keep compatibility temporarily for:

• tool command names consumed by the VS Code extension
• browser globals consumed by shipped notebook content
• extension command IDs and settings keys stored in user configuration
• notebook type IDs and kernelspec IDs that may already exist in user content

Do not prioritize compatibility for:

• internal file names with no runtime lookup
• internal class names not used in serialization, reflection, or generated contracts
• docs-only strings

Preferred compatibility mechanisms by surface:

• .NET public API: type forwarders, compatibility namespaces, wrapper entry points
• TypeScript public API: re-export old names, keep old globals as delegating aliases
• VS Code extension: accept both old and new settings/commands for one migration window
• CLI/tooling: transitional wrapper script or alias if required for extension cutover

Rollback and Hold Criteria

Stop after the current phase and do not continue if any of the following is true.

• notebook startup fails in the local VSIX plus local tool scenario
• the browser JS asset is no longer discoverable by the .NET host
• interface-generator output or contract tests diverge and the owner seam is not yet isolated
• Jupyter install or kernelspec registration produces mismatched IDs
• a persisted identifier change would strand existing user settings or notebooks without a migration path

For each phase, record:

• exact commit hash at phase start
• exact commit hash at phase pass
• known regressions accepted into the next phase
• explicit decision to proceed or hold

Phase 0. Baseline and Safety Net

Objective: establish a reproducible baseline before any rename.

Steps:

1. Record the current failing and passing baseline for build and tests.
2. Build the .NET solution slice needed for the CLI and core libraries.
3. Run the TypeScript unit/contract tests for:
   • src/polyglot-notebooks
   • src/polyglot-notebooks-browser
   • src/polyglot-notebooks-vscode
   • src/polyglot-notebooks-vscode-insiders
4. Run the highest-value .NET tests covering:
   • stdio/http behavior
   • browser/playwright integration
   • Jupyter kernelspec behavior
5. Run the manual notebook flow in NotebookTestScript.dib using the current extension instructions.
6. Save the baseline command list and outcomes.

Validation gate:

• You have a known-good command set for later phase comparisons.
• Any existing failures are documented as pre-existing and are not mistaken for rename regressions.

Deliverables:

• baseline command log
• baseline pass/fail matrix
• frozen rename dictionary draft

Phase 1. Rename .NET Artifact Identities

Objective: rename package IDs, assembly names, project file names, solution entries, and tool identity without yet renaming public API namespaces.

Scope:

• src/dotnet-interactive/dotnet-interactive.csproj
• src/Microsoft.DotNet.Interactive*/**/*.{csproj,fsproj}
• src/interface-generator/interface-generator.csproj
• dotnet-interactive.sln
• project and folder names that directly encode shipped artifact identity
• embedded resource/output names that are artifact-owned rather than API-owned

Rules for this phase:

• Keep runtime/API shim compatibility where possible.
• Do not rename namespaces or public type names yet unless required for a clean build.
• Prefer temporary aliases/shims over simultaneous API churn.

Concrete work items:

1. Rename project file names and project references.
2. Rename PackageId, AssemblyName, RootNamespace only where needed for artifact identity.
3. Rename ToolCommandName from dotnet-interactive to the new command.
4. Update build, packaging, solution, and artifact output references.
5. Update extension-side config defaults only if the tool command must change immediately for the next verification step.

Validation gate:

• dotnet build for the renamed solution/app slice.
• Focused .NET tests for CLI, stdio, HTTP, and packaging-sensitive paths.
• Smoke test that the renamed tool command starts and exposes help.
• Manual e2e: extension/tool wiring using local tool path if config overrides are required.

Suggested validation commands:

• build the affected .NET slice directly rather than using the broad root build first
• run the renamed tool with --help
• run the narrow test suites that cover stdio, HTTP, parser, and browser asset serving

Exit criteria:

• packages and tool can be built and invoked under the new artifact names
• no API/namespace rename has been attempted beyond what this phase strictly needs

Phase 2. Verify End-to-End After .NET Artifact Rename

Objective: prove the fork still works with the new .NET artifact identities before touching TypeScript artifacts.

Steps:

1. Point VS Code extension transport settings at the locally-built renamed tool.
2. Open NotebookTestScript.dib.
3. Execute notebook startup, language switching, package loading, variable sharing, and save/open scenarios.
4. Run .NET browser/playwright tests if available on the machine.
5. Confirm Jupyter install/parser commands still invoke the correct executable.

Validation gate:

• notebook kernel acquisition works
• parser operations work
• browser resource loading still works
• no hardcoded dotnet-interactive assumption remains on the TypeScript side that blocks startup

Manual e2e checklist for this phase:

• install or point to the local extension build
• override transport args to the renamed local tool if needed
• open NotebookTestScript.dib
• execute at least one C#, F#, PowerShell, and JavaScript cell
• verify variable sharing across at least two languages
• verify notebook save and reopen behavior
• verify parser-backed open/save path for .dib and .ipynb

Phase 3. Rename TypeScript Artifact Identities

Objective: rename npm package names, extension package identity, display branding, and distributable JS artifact names without yet renaming TS public APIs.

Scope:

• src/polyglot-notebooks/package.json
• src/polyglot-notebooks-browser/package.json
• src/polyglot-notebooks-vscode/package.json
• src/polyglot-notebooks-vscode-insiders/package.json
• associated lock files, build scripts, localization files, repository metadata, VSIX naming, and artifact outputs

Concrete work items:

1. Rename npm package names and descriptions.
2. Rename VS Code extension name, displayName, publisher, author, repository, and bug URLs as needed.
3. Rename extension activation/display branding that is artifact identity only.
4. Rename generated browser bundle output if it should no longer ship as dotnet-interactive.js.
5. Keep backward-compatible command/config aliases temporarily if installed-user migration matters.

Validation gate:

• npm install, npm run compile, and npm run test in all four TS package roots.
• extension packages can still be built locally.
• any renamed browser bundle is still embedded/served correctly by the .NET side.

Additional cutover caution:

• if the browser bundle name changes here, keep the old served resource path alive until Phase 7 or later unless all .NET call sites move in the same phase and the browser contract tests pass immediately

Exit criteria:

• TypeScript packages and VSIX identities reflect the new fork branding.
• public TS/browser symbol names remain unchanged unless strictly necessary.

Phase 4. Verify End-to-End After TypeScript Artifact Rename

Objective: confirm that packaging and startup still work after the TypeScript artifact rename wave.

Steps:

1. Install the locally built VSIX with the new extension identity.
2. Configure transport/parser settings to the renamed local tool if not already defaulted.
3. Re-run NotebookTestScript.dib.
4. Run VS Code common tests for both stable and insiders packages.
5. Run browser contract tests for the shipped JS bundle.

Validation gate:

• extension installs under new identity
• notebook activation events still fire
• commands/settings still resolve correctly
• browser JS asset loads with the new file name if renamed

Manual e2e checklist for this phase:

• install the newly named VSIX
• verify the extension appears under the new display identity
• open both a .dib notebook and a Jupyter notebook if available
• verify variable explorer and command palette commands still work
• verify acquisition or launch paths do not reference the old package identity unexpectedly

Phase 5. Rename .NET Public APIs and Namespaces

Objective: rename Microsoft.DotNet.Interactive* namespaces and public type names across .NET runtime code after artifact stability is already proven.

Why this is separated:

• this is the widest source-compatibility change in the repository
• it will impact tests, samples, generated code, extension loaders, reflection, and package consumers

Concrete work items:

1. Rename namespaces from Microsoft.DotNet.Interactive... to the new prefix.
2. Rename assembly-qualified references, reflection lookups, and extension entry points.
3. Regenerate any interface-generator outputs that depend on renamed .NET types.
4. Update package references and using/imports across tests and samples.
5. Decide whether to ship temporary compatibility namespaces or type-forwarders.
6. Review serializers, diagnostics, resource names, and any string-based type references for old namespace values.

Validation gate:

• full .NET build for the affected tree
• focused tests for:
  • src/dotnet-interactive.Tests/**
  • src/Microsoft.DotNet.Interactive.Browser.Tests/**
  • src/Microsoft.DotNet.Interactive.Jupyter.Tests/**
  • high-value package-specific tests for connectors/extensions
• verify extension loading from extension.dib scenarios

Additional audit checklist for this phase:

• reflection over type names
• string-based namespace assumptions in snapshots or approved files
• kernelspec and parser payloads containing assembly-qualified names
• generated interface files and the tests that pin their shape

Exit criteria:

• runtime code builds under the new namespace family
• generated artifacts and extension entry points agree with the new names

Phase 6. Verify End-to-End After .NET API Rename

Objective: catch the exact class of hardcoded cross-boundary expectations you called out before touching TypeScript API names.

Most likely failure points in this phase:

• generated interface or contract mismatches
• JS resource lookups still using old embedded names
• kernelspec metadata assuming old extension/tool IDs
• transport/config code still constructing old command lines
• tests or startup code using reflection over old namespaces

Validation gate:

• rerun notebook workflow in VS Code
• rerun browser contract tests
• rerun Jupyter install/startup checks
• confirm that startup, cell execution, variable sharing, and parser operations still behave correctly

This is the best point to pause and inspect any remaining old-name dependencies before renaming TypeScript public APIs.

Phase 7. Rename TypeScript Public APIs and Client Contracts

Objective: rename browser globals, channel interfaces/classes, exported client names, and other TS public symbols after the .NET API side is stable.

Scope examples:

• createDotnetInteractiveClient
• getDotnetInteractiveScope
• DotnetInteractiveScope
• DotnetInteractiveChannel
• StdioDotnetInteractiveChannel
• any generated TS interfaces or contract names derived from .NET

Concrete work items:

1. Rename TS symbols in browser package source.
2. Rename mirrored VS Code common/client symbols in stable and insiders copies.
3. Update tests first where possible to expose remaining old-name assumptions.
4. Consider temporary compatibility exports/globals for one migration window.
5. Update .NET resource references if the browser bundle name also changes in this phase.
6. Keep the old browser globals delegating to the new names until the final ID cleanup phase unless you explicitly decide to break existing notebook-authored script content.

Validation gate:

• browser package tests
• polyglot-notebooks core package tests
• VS Code common tests in both stable and insiders
• manual notebook run covering HTML/JavaScript output and variable APIs

Additional audit checklist for this phase:

• global window assignments in browser init code
• imports/exports in both stable and insiders extension copies
• any generated contract names consumed by tests
• any notebook-authored JavaScript snippets checked into the repo that call the old globals directly

Exit criteria:

• TypeScript public APIs no longer expose the old trademark-bearing naming
• client/server protocol remains intact

Phase 8. Verify End-to-End After TypeScript API Rename

Objective: prove the final client-side rename wave did not silently break runtime protocol assumptions.

Checks:

1. Install local VSIX and run NotebookTestScript.dib again.
2. Verify startup, subkernel switching, completions, diagnostics, variable explorer, parser actions, and notebook save/open.
3. Verify browser output features backed by the shipped JS client.
4. Re-run any Playwright-backed .NET browser tests available on the environment.

Phase 9. Rename VS Code/Jupyter IDs, Commands, Settings, and Migration Shims

Objective: clean up the last layer of externally visible IDs after both runtime halves are already operating under the new brand.

Scope:

• extension command IDs
• config keys under dotnet-interactive.*
• notebook type IDs and activation events
• kernelspec IDs and display names
• marketplace/package references in docs and tests

Why last:

• these IDs are often persisted in user settings and notebooks
• changing them early creates avoidable install/upgrade friction while the runtime is still moving

Recommended tactic:

• support old and new IDs in parallel for one transition window where practical
• log deprecation warnings before removing the old names

Migration work items:

1. Introduce new settings keys and command IDs.
2. Read old settings keys as fallback.
3. Register old and new commands to the same handler during the migration window.
4. Support old notebook type or kernelspec IDs where the hosting platform allows it.
5. Remove the old IDs only after at least one stable internal pass of the complete notebook workflow.

Validation gate:

• existing notebooks still open
• new notebooks use only new IDs
• extension settings migration works or is clearly documented
• Jupyter kernelspec install/register uses new IDs and titles

Phase 10. Documentation, Samples, and Cleanup

Objective: sweep the broad but lower-risk surfaces only after product/runtime identities are stable.

Scope:

• README.md
• docs/**
• samples/**
• notebooks, screenshots, marketplace links, package references, badges, and troubleshooting text

Validation gate:

• spot-check samples with the renamed tool/package identities
• docs no longer instruct users to install or reference trademark-bearing fork-specific names

Deliverables:

• final rename dictionary marked complete
• migration notes for downstream consumers
• explicit list of intentionally retained legacy aliases, if any

Suggested Validation Matrix by Phase

Reusable phase-gate record

Capture this for every phase:

• scope changed
• compatibility shims added
• automated commands run
• manual e2e scenarios run
• pass/fail result
• rollback point
• go/no-go decision

After .NET-side phases

• dotnet build for app/core/projects touched in that phase
• targeted xUnit suites for CLI, stdio, HTTP, Jupyter, browser
• local tool invocation smoke test

After TypeScript-side phases

• npm run compile
• npm run test
• browser contract tests
• VS Code common tests for both stable and insiders copies

After every major wave

• local VSIX install
• manual NotebookTestScript.dib walkthrough
• parser open/save test for .dib and .ipynb
• startup test with the locally-built tool and extension together

Hardcoded Expectation Hotspots to Audit Early

These are the places most likely to fail if one side moves before the other.

• extension config defaults that shell out to dotnet-interactive
• browser global names in src/polyglot-notebooks-browser/src/library-init.ts
• embedded resource name dotnet-interactive.js and server-side file provider lookups
• tests asserting extension ID ms-dotnettools.dotnet-interactive-vscode
• tests asserting kernelspec kernel_id equals dotnet-interactive
• notebook activation events using onNotebook:dotnet-interactive
• generated interface contracts between interface-generator and TS consumers
• documentation or samples used as manual smoke tests that still assume old package/tool names

Persisted-State Hotspots

These need migration attention, not just source renaming.

• user settings under dotnet-interactive.*
• installed kernelspec metadata and local Jupyter registrations
• notebook metadata containing language IDs or notebook type markers
• approved or snapshot test files pinning extension IDs, kernel IDs, and asset names
• any CI/release artifact naming that downstream automation depends on

Suggested Commit Structure

Keep commits attributable to the rename wave.

1. preflight baseline and rename dictionary
2. .NET artifact rename
3. e2e verification after .NET artifact rename
4. TypeScript artifact rename
5. e2e verification after TypeScript artifact rename
6. .NET API rename
7. e2e verification after .NET API rename
8. TypeScript API rename
9. e2e verification after TypeScript API rename
10. persisted IDs, settings migration, docs, and cleanup

Final Acceptance Criteria

The rename effort is complete only when all of the following are true.

• no shipped package, extension, tool, browser global, or public API in the fork uses Microsoft-owned trademark-bearing product identity without an explicit legal reason
• the local tool, local VSIX, parser flow, and notebook workflow all pass together
• Jupyter install/register works with the new IDs
• browser bundle loading and variable/client contracts are stable under the new names
• docs and samples point only to the new fork identity
• any retained compatibility aliases are documented with an explicit removal phase or are intentionally permanent

Recommended Execution Discipline

For each phase:

1. rename one identity layer only
2. build the smallest affected slice immediately
3. run the narrowest automated tests that can disconfirm the phase
4. run at least one notebook-driven e2e smoke test before continuing
5. only then widen to the next identity layer

This keeps the client-server breakpoints visible and makes failures attributable to the last rename wave instead of to the entire repository moving at once.

[sassdawe]

Rename Dictionary

Use this file to freeze the old-to-new identifier map before implementation starts. Do not begin code renames until all shipped identities that matter to a given phase have an approved replacement.

Placeholder Tokens

Use neutral placeholders until the fork's branding is finalized.

• <new-publisher>: publisher, package owner, or organization.
• <new-brand>: product family name replacing old branding.
• <new-cli-command>: CLI or tool command replacing the old command.
• <new-dotnet-prefix>: .NET namespace and package prefix.
• <new-ts-prefix>: TypeScript or browser API prefix.
• <new-browser-bundle>: shipped JavaScript asset name.
• <new-notebook-id>: notebook type identity.
• <new-kernel-title>: kernel display title.

Status Legend

• proposed: candidate replacement exists but is not yet approved.
• approved: safe to implement in the assigned phase.
• deferred: intentionally kept for compatibility or later cleanup.
• legacy-alias: old name retained temporarily after the new name ships.

Dictionary Fields

Old identifier	Proposed new identifier	Identifier class	Owning path or package	First change phase	Compatibility alias	Last old-name support phase	Validation proof	Status	Notes
Microsoft.dotnet-interactive	<new-dotnet-prefix>.<new-cli-command>	artifact	src/dotnet-interactive/dotnet-interactive.csproj	1	<yes/no/optional>	<phase-or-n/a>	<command-or-scenario>	proposed	<notes>
dotnet-interactive	<new-cli-command>	artifact	src/dotnet-interactive/dotnet-interactive.csproj	1	<yes/no/optional>	<phase-or-n/a>	<command-or-scenario>	proposed	<notes>
Microsoft.DotNet.Interactive	<new-dotnet-prefix>	public API	src/Microsoft.DotNet.Interactive/Microsoft.DotNet.Interactive.csproj	5	<yes/no/optional>	<phase-or-n/a>	<command-or-scenario>	proposed	<notes>
@microsoft/polyglot-notebooks	@<new-publisher>/<new-brand>-notebooks	artifact	src/polyglot-notebooks/package.json	3	<yes/no/optional>	<phase-or-n/a>	<command-or-scenario>	proposed	<notes>
microsoft.dotnet.interactive.js	<new-brand>.interactive.js	artifact	src/polyglot-notebooks-browser/package.json	3	<yes/no/optional>	<phase-or-n/a>	<command-or-scenario>	proposed	<notes>
dist/dotnet-interactive.js	dist/<new-browser-bundle>	artifact	src/polyglot-notebooks-browser/package.json	3	<yes/no/optional>	<phase-or-n/a>	<command-or-scenario>	proposed	<notes>
createDotnetInteractiveClient	create<new-ts-prefix>Client	public API	src/polyglot-notebooks-browser/src/library-init.ts	7	<yes/no/optional>	<phase-or-n/a>	<command-or-scenario>	proposed	<notes>
getDotnetInteractiveScope	get<new-ts-prefix>Scope	public API	src/polyglot-notebooks-browser/src/library-init.ts	7	<yes/no/optional>	<phase-or-n/a>	<command-or-scenario>	proposed	<notes>
dotnet-interactive-vscode	<new-brand>-interactive-vscode	artifact	src/polyglot-notebooks-vscode/package.json	3	<yes/no/optional>	<phase-or-n/a>	<command-or-scenario>	proposed	<notes>
ms-dotnettools	<new-publisher>	artifact	src/polyglot-notebooks-vscode/package.json	3	<yes/no/optional>	<phase-or-n/a>	<command-or-scenario>	proposed	<notes>
Polyglot Notebooks	<new-brand> Notebooks	artifact	src/polyglot-notebooks-vscode/package.json	3	<yes/no/optional>	<phase-or-n/a>	<command-or-scenario>	proposed	<notes>
Microsoft Corporation	<new-publisher>	artifact	src/polyglot-notebooks-vscode/package.json	3	<yes/no/optional>	<phase-or-n/a>	<command-or-scenario>	proposed	<notes>
ms-dotnettools.dotnet-interactive-vscode	<new-publisher>.<new-brand>-interactive-vscode	persisted ID	src/polyglot-notebooks-vscode/package.json	9	<yes/no/optional>	<phase-or-n/a>	<command-or-scenario>	proposed	<notes>
dotnet-interactive.acquire	<new-notebook-id>.acquire	persisted ID	src/polyglot-notebooks-vscode/package.json	9	<yes/no/optional>	<phase-or-n/a>	<command-or-scenario>	proposed	<notes>
dotnet-interactive.kernelTransportArgs	<new-notebook-id>.kernelTransportArgs	persisted ID	src/polyglot-notebooks-vscode/package.json	9	<yes/no/optional>	<phase-or-n/a>	<command-or-scenario>	proposed	<notes>
dotnet-interactive.notebookParserArgs	<new-notebook-id>.notebookParserArgs	persisted ID	src/polyglot-notebooks-vscode/package.json	9	<yes/no/optional>	<phase-or-n/a>	<command-or-scenario>	proposed	<notes>
dotnet-interactive.kernelTransportWorkingDirectory	<new-notebook-id>.kernelTransportWorkingDirectory	persisted ID	src/polyglot-notebooks-vscode/package.json	9	<yes/no/optional>	<phase-or-n/a>	<command-or-scenario>	proposed	<notes>
dotnet-interactive.interactiveToolSource	<new-notebook-id>.interactiveToolSource	persisted ID	src/polyglot-notebooks-vscode/package.json	9	<yes/no/optional>	<phase-or-n/a>	<command-or-scenario>	proposed	<notes>
dotnet-interactive.minimumDotNetSdkVersion	<new-notebook-id>.minimumDotNetSdkVersion	persisted ID	src/polyglot-notebooks-vscode/package.json	9	<yes/no/optional>	<phase-or-n/a>	<command-or-scenario>	proposed	<notes>
dotnet-interactive.requiredInteractiveToolVersion	<new-notebook-id>.requiredInteractiveToolVersion	persisted ID	src/polyglot-notebooks-vscode/package.json	9	<yes/no/optional>	<phase-or-n/a>	<command-or-scenario>	proposed	<notes>
onNotebook:dotnet-interactive	onNotebook:<new-notebook-id>	persisted ID	src/polyglot-notebooks-vscode/package.json	9	<yes/no/optional>	<phase-or-n/a>	<command-or-scenario>	proposed	<notes>
dotnet-interactive	<new-notebook-id>	persisted ID	src/polyglot-notebooks-vscode/package.json	9	<yes/no/optional>	<phase-or-n/a>	<command-or-scenario>	proposed	<notes>
dotnet-interactive-window	<new-notebook-id>-window	persisted ID	src/polyglot-notebooks-vscode/package.json	9	<yes/no/optional>	<phase-or-n/a>	<command-or-scenario>	proposed	<notes>
polyglot-notebook	<new-brand>-notebook	persisted ID	src/polyglot-notebooks-vscode/package.json	9	<yes/no/optional>	<phase-or-n/a>	<command-or-scenario>	proposed	<notes>
polyglot-notebook-window	<new-brand>-notebook-window	persisted ID	src/polyglot-notebooks-vscode/package.json	9	<yes/no/optional>	<phase-or-n/a>	<command-or-scenario>	proposed	<notes>
.NET Interactive (C#)	<new-kernel-title> (C#)	persisted ID	src/polyglot-notebooks-vscode/package.json	9	<yes/no/optional>	<phase-or-n/a>	<command-or-scenario>	proposed	<notes>
.NET Interactive (F#)	<new-kernel-title> (F#)	persisted ID	src/polyglot-notebooks-vscode/package.json	9	<yes/no/optional>	<phase-or-n/a>	<command-or-scenario>	proposed	<notes>
.NET Interactive (PowerShell)	<new-kernel-title> (PowerShell)	persisted ID	src/polyglot-notebooks-vscode/package.json	9	<yes/no/optional>	<phase-or-n/a>	<command-or-scenario>	proposed	<notes>
dotnet tool run dotnet-interactive -- notebook-parser	dotnet tool run <new-cli-command> -- notebook-parser	persisted ID	src/polyglot-notebooks-vscode/package.json	9	<yes/no/optional>	<phase-or-n/a>	<command-or-scenario>	proposed	<notes>

Approval Checklist

Before a row changes from proposed to approved, confirm all of the following.

• The replacement does not use restricted or trademark-bearing product identity.
• The replacement matches the fork's naming convention across affected platforms and documentation.
• The first-change phase is consistent with phased-rename-plan.md.
• Compatibility intent is explicit for any client-server or persisted-state seam.
• There is at least one command or scenario that proves the new name works.

Review Notes

• Do not guess final names in code from this file until legal or product naming is approved.
• Add rows whenever a new shipped identity is discovered in rename-surface-inventory.md.
• Keep deferred legacy aliases in this file until they are intentionally removed.

[sassdawe]

Rename Surface Inventory

This inventory groups the concrete rename surfaces that will need attention when removing Microsoft-owned trademarks from the fork.

1. .NET Artifact Identity Surfaces

These are the highest-risk packaging and assembly identifiers because they flow into NuGet, the .NET tool, assembly names, root namespaces, embedded resources, and test expectations.

• src/dotnet-interactive/dotnet-interactive.csproj
  • PackageId: Microsoft.dotnet-interactive
  • ToolCommandName: dotnet-interactive
  • AssemblyName: Microsoft.DotNet.Interactive.App
  • RootNamespace: Microsoft.DotNet.Interactive.App
  • embedded JS resource path includes dist/dotnet-interactive.js
• src/Microsoft.DotNet.Interactive/Microsoft.DotNet.Interactive.csproj
  • PackageId: Microsoft.DotNet.Interactive
• src/Microsoft.DotNet.Interactive.*/*.{csproj,fsproj}
  • package IDs, assembly names, project references, and root namespaces consistently use Microsoft.DotNet.Interactive.*
• src/interface-generator/interface-generator.csproj
  • AssemblyName and RootNamespace use Microsoft.DotNet.Interactive.InterfaceGen.App
• dotnet-interactive.sln
  • project names and paths expose current product naming throughout the solution graph

2. .NET Public API and Namespace Surfaces

These affect consumers, source compatibility, reflection, serialization, generated code, and tests.

• namespace Microsoft.DotNet.Interactive... throughout src/Microsoft.DotNet.Interactive*
• using Microsoft.DotNet.Interactive... throughout runtime code, tests, samples, and docs
• extension entry points such as Microsoft.DotNet.Interactive.DuckDB.KernelExtension.Load(...)
• CLI/application namespaces under Microsoft.DotNet.Interactive.App...
• generated or contract-sensitive names referenced by tests such as TypeScriptInterfacesContractTests

3. TypeScript Package and Browser API Surfaces

These are the main TypeScript/public JavaScript branding surfaces.

• src/polyglot-notebooks/package.json
  • package name: @microsoft/polyglot-notebooks
• src/polyglot-notebooks-browser/package.json
  • package name: microsoft.dotnet.interactive.js
  • description and author reference Microsoft
  • output artifact name is dist/dotnet-interactive.js
• src/polyglot-notebooks-browser/src/library-init.ts
  • global functions: getDotnetInteractiveScope, createDotnetInteractiveClient
  • runtime type names: DotnetInteractiveScopeContainer, DotnetInteractiveScope
• src/polyglot-notebooks-vscode-common/src/DotnetInteractiveChannel.ts
  • interface name DotnetInteractiveChannel
• src/polyglot-notebooks-vscode-common/src/stdioDotnetInteractiveChannel.ts
  • class name StdioDotnetInteractiveChannel
• mirrored copies of the same channel/client names exist in:
  • src/polyglot-notebooks-vscode/**
  • src/polyglot-notebooks-vscode-insiders/**

4. VS Code Extension Identity Surfaces

These are release-critical because they affect upgrade behavior, command names, settings, notebook type IDs, activation events, VSIX identity, and marketplace continuity.

• src/polyglot-notebooks-vscode/package.json
  • extension name: dotnet-interactive-vscode
  • display name: Polyglot Notebooks
  • publisher: ms-dotnettools
  • author: Microsoft Corporation
  • activation events include onNotebook:dotnet-interactive
  • command IDs include dotnet-interactive.acquire
  • configuration keys include:
    • dotnet-interactive.kernelTransportArgs
    • dotnet-interactive.notebookParserArgs
    • dotnet-interactive.kernelTransportWorkingDirectory
    • dotnet-interactive.interactiveToolSource
    • dotnet-interactive.minimumDotNetSdkVersion
    • dotnet-interactive.requiredInteractiveToolVersion
  • Jupyter kernel titles expose .NET Interactive
• src/polyglot-notebooks-vscode-insiders/package.json
  • same rename class as stable package
• localization files under both extension folders
  • package.nls*.json descriptions and titles must stay aligned with renamed IDs

5. Notebook, Jupyter, and Parser Identity Surfaces

These are cross-boundary IDs that can silently break if the client and server stop agreeing.

• notebook activation and notebook type IDs:
  • dotnet-interactive
  • dotnet-interactive-window
  • polyglot-notebook
  • polyglot-notebook-window
• Jupyter kernel display titles in extension manifests:
  • .NET Interactive (C#)
  • .NET Interactive (F#)
  • .NET Interactive (PowerShell)
• kernelspec metadata in tests references:
  • extension ID ms-dotnettools.dotnet-interactive-vscode
  • kernel ID dotnet-interactive
• parser command wiring in extension config currently shells out to:
  • dotnet tool run dotnet-interactive -- notebook-parser

6. Cross-Boundary Resource and Protocol Surfaces

These are the places most likely to break when one side is renamed before the other.

• JS resource name dotnet-interactive.js
  • embedded by src/dotnet-interactive/dotnet-interactive.csproj
  • served and requested by .NET tests and browser/client code
• browser global contract names:
  • createDotnetInteractiveClient
  • getDotnetInteractiveScope
• VS Code transport/config keys that inject tool command arguments
• interface-generator output and contract tests connecting .NET-generated types to TS expectations

7. Automated Validation Surfaces Already Present

These existing tests are useful as safety rails during phased renames.

• .NET browser/playwright-based tests:
  • src/Microsoft.DotNet.Interactive.Browser.Tests/*.cs
• .NET HTTP/stdio/Jupyter/CLI tests:
  • src/dotnet-interactive.Tests/**
  • src/Microsoft.DotNet.Interactive.Jupyter.Tests/**
• TypeScript browser contract tests:
  • src/polyglot-notebooks-browser/tests/*.test.ts
• TypeScript core package tests:
  • src/polyglot-notebooks/tests/*.test.ts
• VS Code common/client tests for both stable and insiders:
  • src/polyglot-notebooks-vscode/tests/vscode-common-tests/*.test.ts
  • src/polyglot-notebooks-vscode-insiders/tests/vscode-common-tests/*.test.ts
• manual notebook scenario script:
  • NotebookTestScript.dib
• existing guidance for extension validation:
  • MANUAL-TESTING.md
  • src/polyglot-notebooks-vscode/UPDATING-TO-NEW-VERSION-OF-STABLE.md

8. Documentation and Sample Surfaces

These are broad but mechanically simpler once code identities are stable.

• root docs under docs/**
  • product naming, tool commands, package references, marketplace URLs, screenshots, and troubleshooting text
• samples under samples/**
  • using Microsoft.DotNet.Interactive...
  • package references such as Microsoft.DotNet.Interactive.*
  • notebook metadata such as languageId: dotnet-interactive.csharp
• root README and other repository metadata files

9. Planned Rename Order Rationale

Recommended ordering is based on blast radius:

1. .NET artifact names first: they are the source of package/tool identity and are easier to validate with build and .NET tests.
2. TypeScript artifact names second: package/library names and output bundles can be validated with local npm tests.
3. .NET public APIs and namespaces third: this isolates source-level compatibility changes after packaging is stable.
4. TypeScript public APIs fourth: browser globals, channel names, and client contracts can then move in sync with regenerated artifacts.
5. VS Code/Jupyter identifiers and commands last: these are highest-friction for installed tooling and easiest to validate once both runtime halves are already aligned.

[sassdawe]

Some more content https://github.com/sassdawe/Polyglossy-interactive/blob/todo/rename-plan/Fork-n-run/README.md