chore(weights): add 2 repos, adjust 1391 weights

[e35ventura]

Purpose

Operation Laser Beam

Changes Summary

Metric	🥇 Gold	🥈 Silver	🥉 Bronze	Total
Repositories Added	0	2	0	2
Weights Modified	12	54	1325	1391
Net Weight Change	+86.51	-107.94	-3100.70	-3122.13

Added Repositories

Repository	Tier	Branch	Weight
qwibitai/nanoclaw	🥈 silver	main	20.00
paperclipai/paperclip	🥈 silver	main	20.00

[anderdc]

add inactive_at attribute for 3/14/26 as that is last day of synth hackathon submissions

[Desel72]

Hi everyone,

I would like to provide more context regarding the openssl/openssl repository and how its workflow interacts with Gittensor’s credibility scoring.

Recently, I opened three pull requests in the OpenSSL repository:

https://github.com/openssl/openssl/pulls?q=is%3Apr+is%3Aclosed

Two of these PRs were actually accepted and merged by the maintainers. However, OpenSSL does not follow the typical GitHub workflow where pull requests are merged using GitHub’s built-in merge button. Instead, maintainers often merge changes manually into their internal workflow and then close the corresponding PRs on GitHub.

Because of this process, the pull requests appear as “closed” instead of “merged” on GitHub, even though the changes were accepted and integrated into the project.

From Gittensor’s perspective, these PRs are interpreted as unsuccessful contributions, which unexpectedly reduced my credibility score, despite the contributions being accepted upstream.

This creates a mismatch between:

• GitHub’s visible PR status (closed)
• the project’s actual contribution acceptance
• Gittensor’s credibility scoring logic

For contributors working with repositories that use non-standard merge workflows like OpenSSL, this may lead to inaccurate scoring.

Given this situation, I believe it may be worth reviewing whether openssl/openssl should remain in the repository list, or whether additional handling should be implemented for projects that do not use the standard GitHub merge workflow.

I’m sharing this here for the upcoming repository audit so maintainers can evaluate whether:

• the repository should remain supported, or
• special handling should be considered for repositories with non-standard merge processes.

Thank you for taking the time to review this.