fix: disable attestations for Test PyPI to avoid conflict

[jeremyeder]

Problem

The release workflow (#154) failed when publishing to production PyPI with error:

Attestation generation failure: The following distributions already have publish attestations:
* /github/workspace/dist/agentready-2.12.0-py3-none-any.whl.publish.attestation
* /github/workspace/dist/agentready-2.12.0.tar.gz.publish.attestation

Root Cause

The pypa/gh-action-pypi-publish action creates .publish.attestation files during the first publish (Test PyPI). When we try to publish to production PyPI in the same workflow run, it attempts to create attestation files again, causing a conflict.

Solution

• Disable attestations for Test PyPI (we don't need them for testing)
• Keep attestations enabled for production PyPI (required for security)

Testing

This fix allows the workflow to:

1. Publish to Test PyPI without attestations
2. Publish to production PyPI with attestations
3. No file conflicts between the two publish steps

Result

After merging, the next release will successfully publish v2.12.0 (or next version) to both Test PyPI and production PyPI.

🤖 Generated with Claude Code

[github-actions]

🤖 AgentReady Assessment Report

Repository: agentready
Path: /home/runner/work/agentready/agentready
Branch: HEAD | Commit: e87d8be5
Assessed: December 04, 2025 at 5:52 AM
AgentReady Version: 2.12.0
Run by: runner@runnervmoqczp

---

📊 Summary

Metric	Value
Overall Score	80.9/100
Certification Level	Gold
Attributes Assessed	20/30
Attributes Not Assessed	10
Assessment Duration	1.4s

Languages Detected

• Python: 140 files
• Markdown: 100 files
• YAML: 25 files
• JSON: 11 files
• Shell: 6 files

Repository Stats

• Total Files: 330
• Total Lines: 177,634

🎖️ Certification Ladder

• 💎 Platinum (90-100)
• 🥇 Gold (75-89) → YOUR LEVEL ←
• 🥈 Silver (60-74)
• 🥉 Bronze (40-59)
• ⚠️ Needs Improvement (0-39)

📋 Detailed Findings

API Documentation

Attribute	Tier	Status	Score
OpenAPI/Swagger Specifications	T3	⊘ not_applicable	—

Build & Development

Attribute	Tier	Status	Score
One-Command Build/Setup	T2	✅ pass	100
Container/Virtualization Setup	T4	⊘ not_applicable	—

Code Organization

Attribute	Tier	Status	Score
Separation of Concerns	T2	✅ pass	98

Code Quality

Attribute	Tier	Status	Score
Type Annotations	T1	❌ fail	41
Cyclomatic Complexity Thresholds	T3	✅ pass	100
Semantic Naming	T3	✅ pass	100
Structured Logging	T3	❌ fail	0
Code Smell Elimination	T4	⊘ not_applicable	—

❌ Type Annotations

Measured: 33.1% (Threshold: ≥80%)

Evidence:

• Typed functions: 458/1384
• Coverage: 33.1%

📝 Remediation Steps

Add type annotations to function signatures

1. For Python: Add type hints to function parameters and return types
2. For TypeScript: Enable strict mode in tsconfig.json
3. Use mypy or pyright for Python type checking
4. Use tsc --strict for TypeScript
5. Add type annotations gradually to existing code

Commands:

# Python
pip install mypy
mypy --strict src/

# TypeScript
npm install --save-dev typescript
echo '{"compilerOptions": {"strict": true}}' > tsconfig.json

Examples:

# Python - Before
def calculate(x, y):
    return x + y

# Python - After
def calculate(x: float, y: float) -> float:
    return x + y

// TypeScript - tsconfig.json
{
  "compilerOptions": {
    "strict": true,
    "noImplicitAny": true,
    "strictNullChecks": true
  }
}

❌ Structured Logging

Measured: not configured (Threshold: structured logging library)

Evidence:

• No structured logging library found
• Checked files: pyproject.toml
• Using built-in logging module (unstructured)

📝 Remediation Steps

Add structured logging library for machine-parseable logs

1. Choose structured logging library (structlog for Python, winston for Node.js)
2. Install library and configure JSON formatter
3. Add standard fields: timestamp, level, message, context
4. Include request context: request_id, user_id, session_id
5. Use consistent field naming (snake_case for Python)
6. Never log sensitive data (passwords, tokens, PII)
7. Configure different formats for dev (pretty) and prod (JSON)

Commands:

# Install structlog
pip install structlog

# Configure structlog
# See examples for configuration

Examples:

# Python with structlog
import structlog

# Configure structlog
structlog.configure(
    processors=[
        structlog.stdlib.add_log_level,
        structlog.processors.TimeStamper(fmt="iso"),
        structlog.processors.JSONRenderer()
    ]
)

logger = structlog.get_logger()

# Good: Structured logging
logger.info(
    "user_login",
    user_id="123",
    email="user@example.com",
    ip_address="192.168.1.1"
)

# Bad: Unstructured logging
logger.info(f"User {user_id} logged in from {ip}")

Context Window Optimization

Attribute	Tier	Status	Score
CLAUDE.md Configuration Files	T1	✅ pass	100
File Size Limits	T2	❌ fail	56

❌ File Size Limits

Measured: 2 huge, 8 large out of 140 (Threshold: <5% files >500 lines, 0 files >1000 lines)

Evidence:

• Found 2 files >1000 lines (1.4% of 140 files)
• Largest: tests/unit/test_models.py (1192 lines)

📝 Remediation Steps

Refactor large files into smaller, focused modules

1. Identify files >1000 lines
2. Split into logical submodules
3. Extract classes/functions into separate files
4. Maintain single responsibility principle

Examples:

# Split large file:
# models.py (1500 lines) → models/user.py, models/product.py, models/order.py

Dependency Management

Attribute	Tier	Status	Score
Lock Files for Reproducibility	T1	✅ pass	100
Dependency Freshness & Security	T2	⊘ not_applicable	—

Documentation

Attribute	Tier	Status	Score
Concise Documentation	T2	❌ fail	70
Inline Documentation	T2	✅ pass	100

❌ Concise Documentation

Measured: 276 lines, 40 headings, 38 bullets (Threshold: <500 lines, structured format)

Evidence:

• README length: 276 lines (excellent)
• Heading density: 14.5 per 100 lines (target: 3-5)
• 1 paragraphs exceed 10 lines (walls of text)

📝 Remediation Steps

Make documentation more concise and structured

1. Break long README into multiple documents (docs/ directory)
2. Add clear Markdown headings (##, ###) for structure
3. Convert prose paragraphs to bullet points where possible
4. Add table of contents for documents >100 lines
5. Use code blocks instead of describing commands in prose
6. Move detailed content to wiki or docs/, keep README focused

Commands:

# Check README length
wc -l README.md

# Count headings
grep -c '^#' README.md

Examples:

# Good: Concise with structure

## Quick Start
```bash
pip install -e .
agentready assess .

Features

• Fast repository scanning
• HTML and Markdown reports
• 25 agent-ready attributes

Documentation

See docs/ for detailed guides.

Bad: Verbose prose

This project is a tool that helps you assess your repository
against best practices for AI-assisted development. It works by
scanning your codebase and checking for various attributes that
make repositories more effective when working with AI coding
assistants like Claude Code...

[Many more paragraphs of prose...]

</details>

### Documentation Standards

| Attribute | Tier | Status | Score |
|-----------|------|--------|-------|
| README Structure | T1 | ✅ pass | 100 |
| Architecture Decision Records (ADRs) | T3 | ❌ fail | 0 |
| Architecture Decision Records | T3 | ⊘ not_applicable | — |

#### ❌ Architecture Decision Records (ADRs)

**Measured**: no ADR directory (Threshold: ADR directory with decisions)

**Evidence**:
- No ADR directory found (checked docs/adr/, .adr/, adr/, docs/decisions/)

<details><summary><strong>📝 Remediation Steps</strong></summary>


Create Architecture Decision Records (ADRs) directory and document key decisions

1. Create docs/adr/ directory in repository root
2. Use Michael Nygard ADR template or MADR format
3. Document each significant architectural decision
4. Number ADRs sequentially (0001-*.md, 0002-*.md)
5. Include Status, Context, Decision, and Consequences sections
6. Update ADR status when decisions are revised (Superseded, Deprecated)

**Commands**:

```bash
# Create ADR directory
mkdir -p docs/adr

# Create first ADR using template
cat > docs/adr/0001-use-architecture-decision-records.md << 'EOF'
# 1. Use Architecture Decision Records

Date: 2025-11-22

## Status
Accepted

## Context
We need to record architectural decisions made in this project.

## Decision
We will use Architecture Decision Records (ADRs) as described by Michael Nygard.

## Consequences
- Decisions are documented with context
- Future contributors understand rationale
- ADRs are lightweight and version-controlled
EOF

Examples:

# Example ADR Structure

```markdown
# 2. Use PostgreSQL for Database

Date: 2025-11-22

## Status
Accepted

## Context
We need a relational database for complex queries and ACID transactions.
Team has PostgreSQL experience. Need full-text search capabilities.

## Decision
Use PostgreSQL 15+ as primary database.

## Consequences
- Positive: Robust ACID, full-text search, team familiarity
- Negative: Higher resource usage than SQLite
- Neutral: Need to manage migrations, backups

</details>

### Git & Version Control

| Attribute | Tier | Status | Score |
|-----------|------|--------|-------|
| Conventional Commit Messages | T2 | ❌ fail | 0 |
| .gitignore Completeness | T2 | ✅ pass | 100 |
| Branch Protection Rules | T4 | ⊘ not_applicable | — |
| Issue & Pull Request Templates | T4 | ⊘ not_applicable | — |

#### ❌ Conventional Commit Messages

**Measured**: not configured (Threshold: configured)

**Evidence**:
- No commitlint or husky configuration

<details><summary><strong>📝 Remediation Steps</strong></summary>


Configure conventional commits with commitlint

1. Install commitlint
2. Configure husky for commit-msg hook

**Commands**:

```bash
npm install --save-dev @commitlint/cli @commitlint/config-conventional husky

Performance

Attribute	Tier	Status	Score
Performance Benchmarks	T4	⊘ not_applicable	—

Repository Structure

Attribute	Tier	Status	Score
Standard Project Layouts	T1	✅ pass	100
Issue & Pull Request Templates	T3	✅ pass	100
Separation of Concerns	T2	⊘ not_applicable	—

Security

Attribute	Tier	Status	Score
Security Scanning Automation	T4	⊘ not_applicable	—

Testing & CI/CD

Attribute	Tier	Status	Score
Test Coverage Requirements	T2	✅ pass	100
Pre-commit Hooks & CI/CD Linting	T2	✅ pass	100
CI/CD Pipeline Visibility	T3	✅ pass	80

🎯 Next Steps

Priority Improvements (highest impact first):

1. Type Annotations (Tier 1) - +10.0 points potential
   • Add type annotations to function signatures
2. Conventional Commit Messages (Tier 2) - +3.0 points potential
   • Configure conventional commits with commitlint
3. File Size Limits (Tier 2) - +3.0 points potential
   • Refactor large files into smaller, focused modules
4. Concise Documentation (Tier 2) - +3.0 points potential
   • Make documentation more concise and structured
5. Architecture Decision Records (ADRs) (Tier 3) - +1.5 points potential
   • Create Architecture Decision Records (ADRs) directory and document key decisions

---

📝 Assessment Metadata

• AgentReady Version: v2.12.0
• Research Version: v1.0.0
• Repository Snapshot: e87d8be
• Assessment Duration: 1.4s
• Assessed By: runner@runnervmoqczp
• Assessment Date: December 04, 2025 at 5:52 AM

🤖 Generated with Claude Code

[github-actions]

🎉 This PR is included in version 2.12.1 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀