diff --git a/docs/components/ALKiln/setup.mdx b/docs/components/ALKiln/setup.mdx
index 321df33e8..e415a3ea1 100644
--- a/docs/components/ALKiln/setup.mdx
+++ b/docs/components/ALKiln/setup.mdx
@@ -64,7 +64,7 @@ Each type of test has its advantages and disadvantages. This documentation expla
 [^sand]: "The isolation metaphor is taken from the idea of children who do not play well together, so each is given [their] own sandbox to play in alone." - [Wikipedia, Sandbox_(computer_security)](https://en.wikipedia.org/wiki/Sandbox_(computer_security))
 
 
-## Recommended setup: <!-- GitHub+You --> <GTOYS/> {#recommended}
+## Recommended setup: GitHub+You™ {#recommended}
 
 <GTOYS/> tests are the O.G. ALKiln tests and mix well with most docassemble server configurations and needs. Like other GitHub tests, you set them up for each repository separately.
 
@@ -124,7 +124,7 @@ You can wait to write more complex tests till your code is more stable. "Stable"
 To learn how to do more with tests, you can read more about [writing tests](writing_tests.mdx) and more about [test files](writing_tests.mdx#test-files).
 
 
-## <!-- ALKilnInThePlayground --> <AutoDIY/> tests {#diy-how-to}
+## ALKilnInThePlayground™ tests {#diy-how-to}
 
 If you set up <AutoDIY/> tests, any developer that logs in can run tests on any of their Projects. You only have to do this once. You can read more details and the pros and cons of <AutoDIY/> tests below.
 
@@ -163,7 +163,7 @@ It also helps to have a Project with at least one ALKiln test in it, but you can
 If you are ready to start running tests, you can read about how to [add our example test](#first-test), [write tests](writing_tests.mdx), or continue the above interview to [run your tests](writing_tests.mdx#trigger_autodiy).
 
 
-## <!-- GitHub Sandbox --> <KittyLitter/> tests (advanced) {#sandbox-how-to}
+## GitHub Sandbox™ tests (advanced) {#sandbox-how-to}
 
 The <KittyLitter/> tests are the most secure because they never interact with your server. ALKiln makes a server on GitHub itself and runs the tests there.
 
@@ -218,7 +218,7 @@ Then edit the new workflow to look like  -->
 If you are ready to start running tests, you can read about how to [add our example test](#first-test), [write tests](writing_tests.mdx), or [trigger and run <KittyLitter plain={true}/> tests on GitHub](writing_tests.mdx#trigger-tests).
 
 
-## <!-- GitHub+You --> <GTOYS/> test details {#githubNyou-details}
+## GitHub+You™ test details {#githubNyou-details}
 
 <GTOYS plain={true}/> tests run in GitHub whenever a developer commits code to the GitHub repository of the package. As you can read below, to use this type of test we strongly recommend you create a [developer account](security.mdx#test-accounts) for ALKiln on your server, a "testing account".
 
@@ -303,7 +303,7 @@ For some people:
 <!-- [^manually]: It is possible for you to set up <GTOYS/> tests manually on your own. You must understand the process already. If you do this by hand, you must also have admin access to the GitHub repository. -->
 
 
-## <!-- ALKilnInThePlayground --> <AutoDIY/> test details {#diy-details}
+## ALKilnInThePlayground™ test details {#diy-details}
 
 <!-- Confusion about "Auto" and "manual" -->
 
@@ -350,7 +350,7 @@ For some people:
 - If you have `restrict input variables` set to `True` in your server's config and have signature screens in the interview you are testing, you *must* have the [trigger variable HTML](writing_tests.mdx#special-html) in your interview for signatures.
 
 
-## <!-- GitHub Sandbox --> <KittyLitter/> test details {#sandbox-details}
+## GitHub Sandbox™ test details {#sandbox-details}
 
 Any developer will [trigger <KittyLitter plain={true}/> tests when they commit code to GitHub](writing_tests.mdx#trigger-tests). They create their own docassemble server on GitHub and run tests there.