feat: Refactor repository for TTA.dev framework focus

[theinterneti]

This PR refactors the TTA.dev repository to align with its new core purpose: exclusively containing the framework for building AI agents. See detailed description in the PR body on GitHub.

[Copilot]

Pull Request Overview

This PR performs a comprehensive repository reorganization, transitioning TTA.dev from a multi-application repository to a focused framework repository. The changes archive historical documentation, deprecated packages, and agent session logs while maintaining core framework functionality.

Reviewed Changes

Copilot reviewed 94 out of 1502 changed files in this pull request and generated 1 comment.

File	Description
_DEPRECATED/archive/reports_and_logs/*.md	Archives 16 comprehensive agent session reports documenting ACE integration, adaptive primitives implementation, and TODO completion workflows
_DEPRECATED/archive/packages-under-review/js-dev-primitives/shell.nix	Archives experimental JavaScript primitives package Nix configuration
.gitmodules	Removes tta.prod submodule reference, aligning with framework-only focus

Comments suppressed due to low confidence (1)

.gitmodules:1

• The .gitmodules file is being completely removed. If the tta.prod submodule directory still exists in the working tree, this change alone will not remove it. After this PR is merged, developers should run git submodule deinit -f tta.prod and rm -rf tta.prod to fully remove the submodule from their local checkouts. Consider adding a migration note to the PR description or CHANGELOG.

[Copilot]

The archived session reports contain valuable institutional knowledge about agent workflows, ACE integration patterns, and implementation decisions. Consider extracting key learnings into a condensed "lessons learned" or "historical decisions" document in the active documentation before archiving, so future contributors can access this knowledge without navigating deprecated content.

To fix the problem, we must stop using the insecure MD5 hashing algorithm and use a strong, modern alternative instead. For deterministic partitioning, a collision-resistant algorithm such as SHA-256 is advisable. The fix is simple: in the assign_user_to_variant method of ContinuousImprovement, change the call from hashlib.md5(hash_input.encode()).hexdigest() to hashlib.sha256(hash_input.encode()).hexdigest(). This requires no other functional change, as both methods return a hexadecimal string suitable for conversion to an integer, preserving the original bucketing logic. The code is already importing hashlib, so no new imports are needed. Only the relevant line (411) should be changed.

Sensitive data, like API keys, should never be logged (even partially). The fix is to avoid printing the API key value (or a slice of it) entirely. Instead, log a generic message stating that the API key was set (without displaying any portion), or—if more precise debugging is needed—print only a safe indication like the length of the API key or, preferably, nothing at all.

Specifically:

• In framework/examples/e2b-validation/test_direct_sdk.py, change line 21 from print(f"✅ API key set: {api_key[:20]}...") to a safe alternative such as print(f"✅ API key set."), or at most, print(f"✅ API key set (length: {len(api_key)}).").
• No additional imports or methods are needed.

To fix the problem, modify the log statement on line 24 so that it does not include any component/substring of the actual API key. You should not print the value or part of the key, but you may indicate non-sensitive data such as the length of the key, that a key is present, or that it was loaded successfully. This preserves the intent of confirming the key's existence without leaking sensitive information.

Specifically:

• Change line 24 from printing a partial key (api_key[:20]) to a message stating that the API key was loaded, optionally including its length for debugging.
• No imports or helper methods are necessary.
• Only line 24 in test_primitive_with_template() needs to be changed.

---

To fix this problem, avoid printing or logging any portion of sensitive credentials such as API keys. The affected region is line 147 in framework/examples/test_llm_integration.py, where the API key (even partially masked) is displayed.

• Instead, you can confirm the presence of the key without showing its value or its parts.
• For example, replace the line with a generic confirmation message such as "✅ API Key Found."
• No additional imports or definitions are needed. Only a single line change is sufficient.

---

To resolve this issue, the log line should be changed so that it does not print any portion of the sensitive secret key. Instead, it can log a generic confirmation that a webhook secret has been set or loaded, its presence, or its length, if needed. For debugging (in development only), it can be helpful to print masked version (e.g., "********"), but in production, even that is typically omitted.

The fix requires:

• In framework/packages/tta-dev-primitives/examples/e2b_webhook_monitoring_server.py, line 270, replace the log line:

  print(f"🔑 Using webhook secret: {WEBHOOK_SECRET[:8]}...")

  with something like:

  print("🔑 Webhook secret is set." if WEBHOOK_SECRET else "⚠️ Webhook secret is NOT set!")

  Optionally, log the length/hash of the key, but never any cleartext part.

No new imports or methods are needed.

To fix this problem, the framework/scripts/validate_secrets.py script should stop logging the potentially sensitive environment value in clear text. The simplest and safest fix is to remove or redact the logging of this value on line 65. Instead of printing the actual environment value from the config, print a placeholder (e.g., "[REDACTED]") or a fixed string ("Set", etc.), or simply omit it. This avoids leaking the value while retaining user feedback that the environment is configured.

Changes are only needed to this line.
No new imports or code structure changes are needed—just an edit to the print statement.
No new dependencies are required.

To address this, rather than logging the debug config value directly (which is sourced from the environment and could be sensitive under certain configurations), we should log only whether debug mode is active, without exposing the actual underlying value.
The simplest approach:

• Instead of print(f" Debug Mode: {config.get('debug', False)}"), print a simple, non-revealing status, such as "Debug Mode: enabled" or "Debug Mode: disabled".
• This avoids leaking environment-derived or secret-linked values, and conforms to best practices.
• Only edit the print line in framework/scripts/validate_secrets.py at line 66.
  No additional imports or definitions are needed.

---

The best solution is to avoid printing any field derived from or reflecting secret values or sensitive configuration, except those explicitly known to be safe (such as "enabled" flags or port numbers known not to be sensitive). The safe approach is to defensively extract only the specific metrics fields you know are safe to disclose—namely, likely just the boolean enabled and port number if these are not sensitive.

1. Inspect the metrics dict from config (config['metrics']) and print only the values absolutely known to be non-secret (e.g., enabled flag, numeric port).
2. Avoid printing the entire metrics config, any API keys, tokens, or any configuration field not reviewed to be non-sensitive.
3. Optionally, add a comment clarifying that only non-sensitive fields are printed for future maintainers.

Therefore, update lines 67 and 68 in validate_secrets.py to:

• Print enabled and port from config['metrics'] if present, with explicit fallback.
• Only display the values explicitly.

No new imports or special libraries are needed.

---

To fix the issue, we should avoid logging the actual port value from the metrics config, as it may be sourced from a sensitive environment variable or be considered secret. Instead, we can log only whether metrics are enabled (already present) and omit the port, or log a generic placeholder ("[hidden]" or similar). This can be done by replacing the line that prints the metrics port with a message that does not include or reveal the port value. Only the following file and block need to be changed: the print statement on line 68 in framework/scripts/validate_secrets.py.

No additional imports or methods are needed. The rest of the code (metrics collection, etc.) is untouched.

---

The best way to fix the problem is to avoid logging any substring or masked portion of the secret values. Instead, the code should only indicate whether the key is present and of valid format for each service. In framework/scripts/validate_secrets.py, within the API Key Validation loop, replace the line that prints the masked secret with a confirmation that the secret is set and its format validated, without exposure of its contents (even partially). You can optionally display the length or a generic "[REDACTED]" placeholder to confirm presence, but do not output even a fragment. No new imports or external dependencies are required.

[theinterneti]

This PR is relevant to the framework-first strategy but has significant merge conflicts that require manual resolution.

[theinterneti]

Superseded by PR #100 which consolidates the valuable work from this refactor into a clean, production-ready implementation.