🔧 add context7 integration configuration

[gimlichael]

This pull request integrates the Context7 widget into the documentation site and adds its configuration. The main changes are the addition of the Context7 script to the documentation footer and the creation of a configuration file for the widget.

Context7 widget integration:

• Added the Context7 widget script to the documentation footer in .docfx/docfx.json to enable new functionality on the site.
• Introduced a new context7.json file containing the widget's URL and public key for configuration.Add context7 widget integration to documentation site. Includes context7.json configuration file and updates docfx footer to load the context7 analytics widget.

[greptile-apps]

Greptile Summary

This PR integrates the Context7 documentation widget by embedding its <script> tag into the DocFX footer and adding a context7.json configuration file at the repository root.

• The _appFooter string in .docfx/docfx.json is extended with a <script async src="https://context7.com/widget.js" data-library="/codebeltnet/carter"> tag; the script loads asynchronously and uses the data-library attribute to identify the project.
• context7.json provides the widget's registration URL and a client-side public key (pk_ZYmd0ipMJCtW5NudkKPxA); the pk_ prefix indicates this key is designed to be public, similar in nature to the Google Analytics tag ID already present in the same file.

Confidence Score: 4/5

Safe to merge for a documentation site; the only notable gap is the absence of an SRI hash on the external script tag.

Both changes are purely additive to a documentation site with no application logic. The third-party script is loaded without an SRI hash, meaning undetected changes to widget.js on the CDN would execute in users' browsers, but the blast radius on a docs site is limited compared to a production app.

.docfx/docfx.json — the footer script tag would benefit from an SRI hash and crossorigin attribute.

Important Files Changed

Filename	Overview
.docfx/docfx.json	Appends a context7 widget <script> tag to the _appFooter HTML string; functional but loads an unversioned third-party script without an SRI hash.
context7.json	New configuration file for the context7 widget, containing the site URL and a client-side public key (pk_ prefix) that is intended to be publicly accessible.

Sequence Diagram

sequenceDiagram
    participant Browser
    participant DocFX as DocFX Site
    participant CDN as context7.com CDN

    Browser->>DocFX: GET /docs/page
    DocFX-->>Browser: HTML with footer script tag
    Browser->>CDN: GET /widget.js (no SRI validation)
    CDN-->>Browser: widget.js
    Browser->>DocFX: GET /context7.json
    DocFX-->>Browser: url + public_key
    Browser->>CDN: Register widget with public_key and data-library
    CDN-->>Browser: Widget rendered on page

Loading

Prompt To Fix All With AI

Fix the following 1 code review issue. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 1
.docfx/docfx.json:54
**Missing Subresource Integrity (SRI) hash on third-party script**

The `widget.js` script is loaded from `context7.com` without an SRI `integrity` attribute. If the CDN is ever compromised or the file is silently changed, the altered script would execute on every documentation page with no browser-side validation. Adding `integrity="sha384-..."` and `crossorigin="anonymous"` pins the script to a known hash and lets browsers reject unexpected content. You can generate the hash with `openssl dgst -sha384 -binary widget.js | openssl base64 -A` against the current file.

_{Reviews (1): Last reviewed commit: "🔧 add context7 integration configuratio..." | Re-trigger Greptile}

[greptile-apps]

Missing Subresource Integrity (SRI) hash on third-party script

The widget.js script is loaded from context7.com without an SRI integrity attribute. If the CDN is ever compromised or the file is silently changed, the altered script would execute on every documentation page with no browser-side validation. Adding integrity="sha384-..." and crossorigin="anonymous" pins the script to a known hash and lets browsers reject unexpected content. You can generate the hash with openssl dgst -sha384 -binary widget.js | openssl base64 -A against the current file.

Prompt To Fix With AI

This is a comment left during a code review.
Path: .docfx/docfx.json
Line: 54

Comment:
**Missing Subresource Integrity (SRI) hash on third-party script**

The `widget.js` script is loaded from `context7.com` without an SRI `integrity` attribute. If the CDN is ever compromised or the file is silently changed, the altered script would execute on every documentation page with no browser-side validation. Adding `integrity="sha384-..."` and `crossorigin="anonymous"` pins the script to a known hash and lets browsers reject unexpected content. You can generate the hash with `openssl dgst -sha384 -binary widget.js | openssl base64 -A` against the current file.

How can I resolve this? If you propose a fix, please make it concise.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!